Re: [Qemu-devel] [PATCH RFT 0/3] iscsi: fix NULL dereferences / races between task completion and abort
Hi Paolo, Am 18.08.2012 23:49, schrieb Paolo Bonzini: Hi Stefan, this is my version of your patch. I think the flow of the code is a bit simpler (or at least matches other implementations of cancellation). Can you test it on your test case? I'm really sorry but your patch doesn't work at all. I'm not even able to start the VM. KVM process hangs and never detaches itself. Greets, Stefan
Re: [Qemu-devel] [PATCH] block-migration: deprecate block migration for the 1.2 release
On Sat, Aug 18, 2012 at 9:08 PM, Paolo Bonzini pbonz...@redhat.com wrote: That's correct. Live block migration will use two ports, both served by the destination, one using NBD and one for RAM/device migration data. It will be a little more complicated than just migrate -b, but nothing that libvirt cannot orchestrate. Will I still be able to cap the migration bandwidth? And how about security? Libvirt can tunnel the data, I believe by passing an fd to qemu, and encrypting the connection with TLS. Thanks, Ruben
Re: [Qemu-devel] qemu log function to print out the registers of the guest
On Fri, Aug 17, 2012 at 03:57:55PM +0400, Max Filippov wrote: On Fri, Aug 17, 2012 at 3:14 PM, 陳韋任 (Wei-Ren Chen) che...@iis.sinica.edu.tw wrote: On Thu, Aug 16, 2012 at 7:49 PM, Steven wangwangk...@gmail.com wrote: [...] I want to get the guest memory address in the instruction mov 0x4(%ebx) %eax, whic is 0x4(%ebx). Since %ebx is not resolved until the execution time, the code in softmmu_header.h does not generate any hit or miss information. Do you know any place that I could resolve the memory access address? Thanks. You'll have to generate code. Look at how helpers work. Hi, Laurent, do you mean the target-i386/op_helper.c/helper.c or the tcg helper? Thanks. What do you mean by resolve the memory access address? Do you want to get guest virtual address for each guest memory access, right? As Max mentioned before (you can also read [1]), there are fast and slow path in QEMU softmmu, tlb hit and tlb miss respectively. Max provided patch for slow path. As for fast path, take a look on tcg_out_tlb_load (tcg /i386/tcg-target.c). tcg_out_tlb_load will generate native code in the code cache to do tlb lookup, I think you cannot use the trick Max used since tcg_out_tlb_load will not be called when the fast path executed, That's why I've posted the following hunk that should have made all accesses go via slow path: Ya, I know. :) Just try to explain what Laurent want to say. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] Windows slow boot: contractor wanted
On 08/17/2012 03:36 PM, Richard Davies wrote: Hi Avi, Thanks to you and several others for offering help. We will work with Avi at first, but are grateful for all the other offers of help. We have a number of other qemu-related projects which we'd be interested in getting done, and will get in touch with these names (and anyone else who comes forward) to see if any are of interest to you. This slow boot problem is intermittent and varys in how slow the boots are, but I managed to trigger it this morning with medium slow booting (5-10 minutes) and link to the requested traces below. The host in question has 128GB RAM and dual AMD Opteron 6128 (16 cores total). It is running kernel 3.5.1 and qemu-kvm 1.1.1. In this morning's test, we have 3 guests, all booting Windows with 40GB RAM and 8 cores each (we have seen small VMs go slow as I originally said, but it is easier to trigger with big VMs): pid 15665: qemu-kvm -nodefaults -m 40960 -smp 8 -cpu host,hv_relaxed \ -vga cirrus -usbdevice tablet -vnc :99 -monitor stdio -hda test1.raw pid 15676: qemu-kvm -nodefaults -m 40960 -smp 8 -cpu host,hv_relaxed \ -vga cirrus -usbdevice tablet -vnc :98 -monitor stdio -hda test2.raw pid 15653: qemu-kvm -nodefaults -m 40960 -smp 8 -cpu host,hv_relaxed \ -vga cirrus -usbdevice tablet -vnc :97 -monitor stdio -hda test3.raw 40+40+40=120, pretty close to your server specs. Are you swapping? -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [RFC-v2 3/6] vhost-scsi: add -vhost-scsi host device for use with tcm-vhost
On Sat, Aug 18, 2012 at 05:36:26PM -0700, Nicholas A. Bellinger wrote:
On Sat, 2012-08-18 at 22:12 +0300, Michael S. Tsirkin wrote:
On Tue, Aug 14, 2012 at 01:31:14PM -0700, Nicholas A. Bellinger wrote:
On Mon, 2012-08-13 at 11:53 +0300, Michael S. Tsirkin wrote:
On Mon, Aug 13, 2012 at 08:35:14AM +, Nicholas A. Bellinger wrote:
From: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
SNIP
+static VHostSCSI *vhost_scsi_add(const char *id, const char *wwpn,
+ uint16_t tpgt)
+{
+VHostSCSI *vs = g_malloc0(sizeof(*vs));
+int ret;
+
+/* TODO set up vhost-scsi device and bind to
tcm_vhost/$wwpm/tpgt_$tpgt */
+fprintf(stderr, wwpn = \%s\ tpgt = \%u\\n, id, tpgt);
+
+ret = vhost_dev_init(vs-dev, -1, /dev/vhost-scsi, false);
This -1 is a hack. You need to support passing in fd from
the monitor, and pass it here.
Mmm, looking at how vhost_net_init + tap.c does this, but am not quite
what fd needs to be propagated up for virtio-scsi - vhost-scsi..
Can you please elaborate on this one a bit more..?
The idea is to allow running as a user without access to
/dev/vhost-scsi.
For this, allow passing in the fd of /dev/vhost-scsi through unix domain
sockets.
Ah, that is a pretty neat trick.. So for vhost-scsi code, this would
mean something along the lines of the following, yes..?
Yes but with one correction. See below.
Thanks MST!
diff --git a/hw/vhost-scsi.c b/hw/vhost-scsi.c
index 4206a75..8af8758 100644
--- a/hw/vhost-scsi.c
+++ b/hw/vhost-scsi.c
@@ -21,6 +21,7 @@ struct VHostSCSI {
const char *id;
const char *wwpn;
uint16_t tpgt;
+int vhostfd;
struct vhost_dev dev;
struct vhost_virtqueue vqs[VHOST_SCSI_VQ_NUM];
QLIST_ENTRY(VHostSCSI) list;
@@ -114,13 +115,32 @@ void vhost_scsi_stop(VHostSCSI *vs, VirtIODevice *vdev)
}
static VHostSCSI *vhost_scsi_add(const char *id, const char *wwpn,
- uint16_t tpgt)
+ uint16_t tpgt, const char *vhostfd_str)
{
-VHostSCSI *vs = g_malloc0(sizeof(*vs));
+VHostSCSI *vs;
int ret;
+vs = g_malloc0(sizeof(*vs));
+if (!vs) {
+error_report(vhost-scsi: unable to allocate *vs\n);
+return NULL;
+}
+vs-vhostfd = -1;
+
+if (vhostfd_str) {
+if (!qemu_isdigit(vhostfd_str[0])) {
+error_report(vhost-scsi: passed vhostfd value is not a
digit\n);
+return NULL;
This let you use an fd which was open at exec
but does not allow for fd to be open later in
case device is hot-plugged.
See net_handle_fd_param - I think you can just rename it
qemu_handle_fd_param to avoid code duplication.
+}
+
+vs-vhostfd = qemu_parse_fd(vhostfd_str);
+if (vs-vhostfd == -1) {
+error_report(vhost-scsi: unable to parse vs-vhostfd\n);
+return NULL;
+}
+}
/* TODO set up vhost-scsi device and bind to tcm_vhost/$wwpm/tpgt_$tpgt
*/
-ret = vhost_dev_init(vs-dev, -1, /dev/vhost-scsi, false);
+ret = vhost_dev_init(vs-dev, vs-vhostfd, /dev/vhost-scsi, false);
if (ret 0) {
error_report(vhost-scsi: vhost initialization failed: %s\n,
strerror(-ret));
@@ -140,7 +160,7 @@ static VHostSCSI *vhost_scsi_add(const char *id, const
char *wwpn,
VHostSCSI *vhost_scsi_add_opts(QemuOpts *opts)
{
const char *id;
-const char *wwpn;
+const char *wwpn, *vhostfd;
uint64_t tpgt;
id = qemu_opts_id(opts);
@@ -164,6 +184,7 @@ VHostSCSI *vhost_scsi_add_opts(QemuOpts *opts)
error_report(vhost-scsi: \%s\ needs a 16-bit tpgt\n, id);
return NULL;
}
+vhostfd = qemu_opt_get(opts, vhostfd);
-return vhost_scsi_add(id, wwpn, tpgt);
+return vhost_scsi_add(id, wwpn, tpgt, vhostfd);
}
diff --git a/qemu-config.c b/qemu-config.c
index 33399ea..2d4884c 100644
--- a/qemu-config.c
+++ b/qemu-config.c
@@ -636,6 +636,9 @@ QemuOptsList qemu_vhost_scsi_opts = {
}, {
.name = tpgt,
.type = QEMU_OPT_NUMBER,
+}, {
+.name = vhostfd,
+.type = QEMU_OPT_STRING,
},
{ /* end of list */ }
},
Re: [Qemu-devel] Windows slow boot: contractor wanted
Avi Kivity wrote: Richard Davies wrote: The host in question has 128GB RAM and dual AMD Opteron 6128 (16 cores total). It is running kernel 3.5.1 and qemu-kvm 1.1.1. In this morning's test, we have 3 guests, all booting Windows with 40GB RAM and 8 cores each (we have seen small VMs go slow as I originally said, but it is easier to trigger with big VMs): 40+40+40=120, pretty close to your server specs. Are you swapping? No - you can see on the top screenshot that there's no swap in use. Richard.
Re: [Qemu-devel] qemu-kvm-1.0.1 - unable to exit if vcpu is in infinite loop
On 08/17/2012 06:04 PM, Jan Kiszka wrote: Can anyone imagine that such a barrier may actually be required? If it is currently possible that env-stop is evaluated before we called into sigtimedwait in qemu_kvm_eat_signals, then we could actually eat the signal without properly processing its reason (stop). Should not be required (TM): Both signal eating / stop checking and stop setting / signal generation happens under the BQL, thus the ordering must not make a difference here. Agree. Don't see where we could lose a signal. Maybe due to a subtle memory corruption that sets thread_kicked to non-zero, preventing the kicking this way. Cannot be ruled out, yet too much of a coincidence. Could be a kernel bug (either in kvm or elsewhere), we've had several before in this area. Is this reproducible? -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH v3 2/7] memory: Flush coalesced MMIO on selected region access
On 08/17/2012 01:55 PM, Jan Kiszka wrote: On 2012-07-10 12:41, Jan Kiszka wrote: On 2012-07-02 11:07, Avi Kivity wrote: On 06/29/2012 07:37 PM, Jan Kiszka wrote: Instead of flushing pending coalesced MMIO requests on every vmexit, this provides a mechanism to selectively flush when memory regions related to the coalesced one are accessed. This first of all includes the coalesced region itself but can also applied to other regions, e.g. of the same device, by calling memory_region_set_flush_coalesced. Looks fine. I have a hard time deciding whether this should go through the kvm tree or memory tree. Anthony, perhaps you can commit it directly to avoid the livelock? Reviewed-by: Avi Kivity a...@redhat.com Anthony, ping? Argh, missed that this series was forgotten. Patch 1 is a bug fix, will resend it separately so that it can make it into 1.2. Will repost the rest once master reopens. My fault, I should have just taken it into memory/core and sent a pull request. Sorry about that. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] memory: could we add extra input param for memory_region_init_io()?
On 08/17/2012 05:52 AM, liu ping fan wrote: Why? Usually there's a 1:1 mapping between object and opaque. Can you show cases where there isn't? As mentioned ahead, setup_cmd646_bar(PCIIDEState *d, int bus_num), Object=@d, but opaque are d-cmd646_bar[bus_num], so that is 1:n mapping. And when I browsing the code, this is the main issue prevent us to transfer from void* to Object* for memory_region_init_io() In this case there is a 1:1 relationship between CMD646BAR and IDEBus. IDEBus is a BusState which is an Object. So this case can be solved easily. Above methods, the process of derive the Object will be hard, we can not tell opaque is Object or not without something like trycatch Take for example e1000. It passes E1000State as the opaque, which is a PCIDevice, which is a DeviceState, which is an Object. So for that device, nothing needs to be done. The same example, in setup_cmd646_bar(PCIIDEState *d, int bus_num), I think we can not decide which is the type for @bar. If using object_dynamic_cast(@bar, TYPE_OBJECT) to tell whether it is Object or not, it will raise exception. No, dynamic cast cannot work on an arbitrary void *. There is only one legitimate case IMO where we don't naturally have an object to work on - device assignment, where all the BARs are equivalent. In that case we can just make the BARs also Objects. Everything else should work naturally with perhaps a little refactoring. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH] qapi: Fix memory leak
On 08/18/12 22:51, Stefan Weil wrote: valgrind report: ==24534== 232 bytes in 2 blocks are definitely lost in loss record 1,245 of 1,601 ==24534==at 0x4824F20: malloc (vg_replace_malloc.c:236) ==24534==by 0x293C88: malloc_and_trace (vl.c:2281) ==24534==by 0x489AD99: ??? (in /lib/libglib-2.0.so.0.2400.1) ==24534==by 0x489B23B: g_malloc0 (in /lib/libglib-2.0.so.0.2400.1) ==24534==by 0x2B4EFC: opts_visitor_new (opts-visitor.c:376) ==24534==by 0x29DEA5: net_client_init (net.c:708) ==24534==by 0x29E6C7: net_init_client (net.c:966) ==24534==by 0x2C2179: qemu_opts_foreach (qemu-option.c:1114) ==24534==by 0x29E85B: net_init_clients (net.c:1008) ==24534==by 0x296F40: main (vl.c:3463) Signed-off-by: Stefan Weil s...@weilnetz.de --- qapi/opts-visitor.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/qapi/opts-visitor.c b/qapi/opts-visitor.c index a59d306..e048b6c 100644 --- a/qapi/opts-visitor.c +++ b/qapi/opts-visitor.c @@ -416,7 +416,7 @@ opts_visitor_cleanup(OptsVisitor *ov) g_hash_table_destroy(ov-unprocessed_opts); } g_free(ov-fake_id_opt); -memset(ov, '\0', sizeof *ov); +g_free(ov); } I don't remember why I thought the object would / should live on. I must have implemented what I thought was safe / correct for the life-cycle, except I got the life-cycle wrong. Face, meet palm. Reviewed-by: Laszlo Ersek ler...@redhat.com Thanks sorry! Laszlo
Re: [Qemu-devel] memory: could we add extra input param for memory_region_init_io()?
On 08/17/2012 10:41 AM, liu ping fan wrote: The same example, in setup_cmd646_bar(PCIIDEState *d, int bus_num), I think we can not decide which is the type for @bar. If using object_dynamic_cast(@bar, TYPE_OBJECT) to tell whether it is Object or not, it will raise exception. And something like omap_mpu_timer_init() in file hw/omap1.c , the opaque(omap_mpu_timer_s) is got from g_malloc0, which makes things even harder to handle. And the DO_CAST can not work for such issue. IMO omap_mpu_timer_s should be a DeviceState. Peter? -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH] qapi: Fix memory leak
On 08/18/12 23:06, Michael Tokarev wrote: On 19.08.2012 00:51, Stefan Weil wrote: +++ b/qapi/opts-visitor.c @@ -416,7 +416,7 @@ opts_visitor_cleanup(OptsVisitor *ov) g_hash_table_destroy(ov-unprocessed_opts); } g_free(ov-fake_id_opt); -memset(ov, '\0', sizeof *ov); +g_free(ov); Shouldn't the function be named opts_visitor_free() or .._destroy() in this case? Or should maybe the caller free ov instead of this function? To me it looks like either both free+rename shoud be made, or none. All of - string-output-visitor.c - string-input-visitor.c - qmp-output-visitor.c - qmp-input-visitor.c - qapi-dealloc-visitor.c free the visitor in *_cleanup(). (Which is not to say they shouldn't all be renamed, only that the patch uni-forms opts-visitor with the rest.) Thanks, Laszlo
[Qemu-devel] [Bug 1035572] Re: Bug in Qemu User Mode
Hi,
I just compiled the testclone.c with Suse Linux 9.0.
It has a Kernel 2.4.21, so never heard anything in its life about NPTL.
On this 2.4.21 Linux, the testclone program with direct calling of clone()
works.
Then I make a try with this testclone on Raspberry Pi and qemu-i386 with
-strace.
The same happens as before:
In the clone() number entries, only the numbers of the childstacks are
different,
all other in the two threads is the same and the message comes: No child
processes
So, the problem in Qemu User mode for a i386 guest depends not on NPTL.
qemu-i386 has a problem, when clone() was called direct, no problem if it is
called via pthread_create,
Dietmar
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1035572
Title:
Bug in Qemu User Mode
Status in QEMU:
New
Bug description:
Hi,
I make an interesting discovery.
My aim is to have a working qemu-i386 on Raspberry Pi.
After long searching in the dark what goes wrong with ANY Qemu version for
User Mode until today,
I find the following: The bug must be in at least one function, that the
program testclone
from the testpackage for i386 in linux-user-test-0.3 calls.
The wrong function is in the part, which enables more than one thread at the
same time, NPTL.
Funny, how I find this out: All the programs from the tests in
linux-user-test-0.3 I can now run succesfull with my new builded qemu-i386 for
Raspi.
But the program testclone does not stop after it gives out all the right
messages.
The program testclone stops on my Desktop computer with Debian Wheezy
installed.
So, the error is not in the program testclone.
So I make a look, what is going on there with strace. With strace you get
informations about all the values in the working program, here testclone.
I see, that the reason, why testclone not stops is in an infinite loop
because of
while (waitpid(pid1, status1, 0) != pid1);
while (waitpid(pid2, status2, 0) != pid2);
at its end is never fullfilled.
This is the reason for the famous error message from Qemu User Mode
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault
stack1 = malloc(STACK_SIZE);
pid1 = clone(thread1_func, stack1 + STACK_SIZE,
CLONE_VM | CLONE_FS | CLONE_FILES | SIGCHLD, hello1);
stack2 = malloc(STACK_SIZE);
pid2 = clone(thread2_func, stack2 + STACK_SIZE,
CLONE_VM | CLONE_FS | CLONE_FILES | SIGCHLD, hello2);
The error happens early in the program testclone. Strace says, it is because
no childprocess at all can be found. So, some basiccalculations in those four
lines must be done wrong from Qemu.
I think, that the adressspace for each thread is calculated wrong, or
overlapps.
Funny, it has nothing to do with the ARM processor. I get exact the same
errormessages, when I run the program testclone on my desktopcompi i386 with a
Wheezy in Qemu and then qemu-i386 testclone.
This is a good message, because it means it is an error, that belongs at
least to the i386 family but I think, every processor in Qemu User Mode is
involved, so until now NPTL does not work.
Today I make a hand by hand calculation with the source code from testclone
and compare it with the values, that Qemu User Mode give. The handcalculated
values should be the same which my
Desktop computer with Wheezy with tesclone produces, but who knows,
Dietmar
PS: I hope, that this is the right source code for testclone. Any help
is welcome:-)!
Code: Select all
#include stdlib.h
#include stdio.h
#include string.h
#include signal.h
#include unistd.h
#include inttypes.h
#include pthread.h
#include sys/wait.h
#include sched.h
int thread1_func(void *arg)
{
int i;
char buf[512];
for(i=0;i10;i++) {
snprintf(buf, sizeof(buf), thread1: %d %s\n, i, (char *)arg);
write(1, buf, strlen(buf));
usleep(100 * 1000);
}
return 0;
}
int thread2_func(void *arg)
{
int i;
char buf[512];
for(i=0;i20;i++) {
snprintf(buf, sizeof(buf), thread2: %d %s\n, i, (char *)arg);
write(1, buf, strlen(buf));
usleep(120 * 1000);
}
return 0;
}
#define STACK_SIZE 16384
void test_clone(void)
{
uint8_t *stack1, *stack2;
int pid1, pid2, status1, status2;
stack1 = malloc(STACK_SIZE);
pid1 = clone(thread1_func, stack1 + STACK_SIZE,
CLONE_VM | CLONE_FS | CLONE_FILES | SIGCHLD, hello1);
stack2 = malloc(STACK_SIZE);
pid2 = clone(thread2_func, stack2 + STACK_SIZE,
CLONE_VM | CLONE_FS | CLONE_FILES | SIGCHLD, hello2);
while (waitpid(pid1, status1, 0) != pid1);
while (waitpid(pid2, status2, 0) != pid2);
printf(status1=0x%x\n, status1);
printf(status2=0x%x\n, status2);
printf(End of clone test.\n);
}
int main(int argc, char
Re: [Qemu-devel] [PATCH 2/2] ISCSI: Force scsi-generic for MMC with blank disks
Il 19/08/2012 01:44, ronnie sahlberg ha scritto: format=raw works ! That then begs the question if would it be possible to force format=raw always for iscsi devices? A iscsi device as far as I can see would always just be a raw block device and there would never be a header on such devices so maybe that would be a solution? While it sounds weird, it is perfectly possible to host a qcow2 image on an iSCSI LUN. So the solution is to make iscsi behave the same as raw-posix and raw-win32 (since they all sit at the same level). Paolo
Re: [Qemu-devel] [PATCH] qapi: Fix memory leak
On 18 August 2012 22:01, Stefan Weil s...@weilnetz.de wrote: valgrind reports a lot more memory leaks which are related to function qemu_allocate_irqs. In many cases, its return value should be free'd. g_malloc / g_free can be avoided by adding a new function void qemu_init_irqs(qemu_irq_handler handler, void *opaque, qemu_irq *irqs, int n); If this is ok, I'll send patches which add and use the new function instead of qemu_allocate_irqs, too. So I think the long term plan is that these will basically go away in favour of some kind of Pin based infrastructure. Given that, it might not be worth doing unless these leaks are more than memory lasts for lifetime of qemu and we don't free it explicitly (maybe you could actual leaks in a hotplug scenario?) -- PMM
[Qemu-devel] [PATCH v2] pl190: fix read of VECTADDR
Signed-off-by: Brendan Fennell bfenn...@skynet.ie
---
hw/pl190.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/hw/pl190.c b/hw/pl190.c
index cb50afb..eddb531 100644
--- a/hw/pl190.c
+++ b/hw/pl190.c
@@ -120,7 +120,8 @@ static uint64_t pl190_read(void *opaque, target_phys_addr_t
offset,
current priority level to that of the current interrupt. */
for (i = 0; i s-priority; i++)
{
-if ((s-level | s-soft_level) s-prio_mask[i])
+/* Ensure that 'i' is current highest priority interrupt on exit */
+if ((s-level | s-soft_level) s-prio_mask[i+1])
break;
}
/* Reading this value with no pending interrupts is undefined.
--
1.7.2.5
Re: [Qemu-devel] memory: could we add extra input param for memory_region_init_io()?
On 19 August 2012 11:12, Avi Kivity a...@redhat.com wrote: On 08/17/2012 10:41 AM, liu ping fan wrote: And something like omap_mpu_timer_init() in file hw/omap1.c , the opaque(omap_mpu_timer_s) is got from g_malloc0, which makes things even harder to handle. And the DO_CAST can not work for such issue. IMO omap_mpu_timer_s should be a DeviceState. Peter? Ideally, yes, but qemu is full of devices that haven't yet made the leap to QOM. omap1 is particularly tricky because I don't actually have any test images for it, so refactoring it is a leap in the dark. [I've tried asking on this list if anybody had test images a couple of times without success.] -- PMM
Re: [Qemu-devel] memory: could we add extra input param for memory_region_init_io()?
On 08/19/2012 02:23 PM, Peter Maydell wrote: On 19 August 2012 11:12, Avi Kivity a...@redhat.com wrote: On 08/17/2012 10:41 AM, liu ping fan wrote: And something like omap_mpu_timer_init() in file hw/omap1.c , the opaque(omap_mpu_timer_s) is got from g_malloc0, which makes things even harder to handle. And the DO_CAST can not work for such issue. IMO omap_mpu_timer_s should be a DeviceState. Peter? Ideally, yes, but qemu is full of devices that haven't yet made the leap to QOM. omap1 is particularly tricky because I don't actually have any test images for it, so refactoring it is a leap in the dark. [I've tried asking on this list if anybody had test images a couple of times without success.] Okay. Most of the options in this thread don't involve wholesale conversion of the opaque parameter in memory_region_init_io() to type Object *, so it's not necessary to convert everything. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] memory: could we add extra input param for memory_region_init_io()?
On 19 August 2012 12:23, Peter Maydell peter.mayd...@linaro.org wrote: Ideally, yes, but qemu is full of devices that haven't yet made the leap to QOM. omap1 is particularly tricky because I don't actually have any test images for it, so refactoring it is a leap in the dark. [I've tried asking on this list if anybody had test images a couple of times without success.] As an aside, maybe we should just delete the omap1 code if we haven't got any way of testing it? -- PMM
Re: [Qemu-devel] [PATCH v2] linux-user: fix emulation of getdents
On Sat, Aug 18, 2012 at 9:56 PM, Dmitry V. Levin l...@altlinux.org wrote:
In case when TARGET_ABI_BITS == 32 HOST_LONG_BITS == 64, the last
byte of the target dirent structure (aka d_type byte) was never copied
from the host dirent structure, thus breaking everything that relies
on valid d_type value, e.g. glob(3).
Signed-off-by: Dmitry V. Levin l...@altlinux.org
Acked-by: Blue Swirl blauwir...@gmail.com
---
linux-user/syscall.c | 8
linux-user/syscall_defs.h | 3 ++-
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 41c869b..adc3270 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -7030,10 +7030,10 @@ abi_long do_syscall(void *cpu_env, int num, abi_long
arg1,
tde-d_ino = tswapal(de-d_ino);
tde-d_off = tswapal(de-d_off);
tnamelen = treclen - (2 * sizeof(abi_long) + 2);
- if (tnamelen 256)
-tnamelen = 256;
-/* XXX: may not be correct */
-pstrcpy(tde-d_name, tnamelen, de-d_name);
+if (tnamelen sizeof(tde-d_name)) {
+tnamelen = sizeof(tde-d_name);
+}
+memcpy(tde-d_name, de-d_name, tnamelen);
de = (struct linux_dirent *)((char *)de + reclen);
len -= reclen;
tde = (struct target_dirent *)((char *)tde + treclen);
diff --git a/linux-user/syscall_defs.h b/linux-user/syscall_defs.h
index 2cfda5a..19fe414 100644
--- a/linux-user/syscall_defs.h
+++ b/linux-user/syscall_defs.h
@@ -258,7 +258,8 @@ struct target_dirent {
abi_longd_ino;
abi_longd_off;
unsigned short d_reclen;
- chard_name[256]; /* We must not include limits.h! */
+ chard_name[257];/* 257 = NAME_MAX + '\0' + d_type, */
+/* we must not include limits.h! */
};
struct target_dirent64 {
--
ldv
Re: [Qemu-devel] [PATCH v2] pl190: fix read of VECTADDR
On Sun, Aug 19, 2012 at 10:59 AM, Brendan Fennell bfenn...@skynet.ie wrote:
Signed-off-by: Brendan Fennell bfenn...@skynet.ie
---
hw/pl190.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/hw/pl190.c b/hw/pl190.c
index cb50afb..eddb531 100644
--- a/hw/pl190.c
+++ b/hw/pl190.c
@@ -120,7 +120,8 @@ static uint64_t pl190_read(void *opaque,
target_phys_addr_t offset,
current priority level to that of the current interrupt. */
for (i = 0; i s-priority; i++)
{
-if ((s-level | s-soft_level) s-prio_mask[i])
+/* Ensure that 'i' is current highest priority interrupt on exit
*/
+if ((s-level | s-soft_level) s-prio_mask[i+1])
Missing braces and spaces around '+', please read CODING_STYLE.
break;
}
/* Reading this value with no pending interrupts is undefined.
--
1.7.2.5
Re: [Qemu-devel] memory: could we add extra input param for memory_region_init_io()?
On Sun, Aug 19, 2012 at 12:03 PM, Peter Maydell peter.mayd...@linaro.org wrote: On 19 August 2012 12:23, Peter Maydell peter.mayd...@linaro.org wrote: Ideally, yes, but qemu is full of devices that haven't yet made the leap to QOM. omap1 is particularly tricky because I don't actually have any test images for it, so refactoring it is a leap in the dark. [I've tried asking on this list if anybody had test images a couple of times without success.] As an aside, maybe we should just delete the omap1 code if we haven't got any way of testing it? Yes, for example start printing warnings when the machine is started to solicit new maintainers. We should apply the same logic elsewhere too. -- PMM
Re: [Qemu-devel] [PATCH RFT 0/3] iscsi: fix NULL dereferences / races between task completion and abort
Il 19/08/2012 09:55, Stefan Priebe ha scritto: Hi Paolo, Am 18.08.2012 23:49, schrieb Paolo Bonzini: Hi Stefan, this is my version of your patch. I think the flow of the code is a bit simpler (or at least matches other implementations of cancellation). Can you test it on your test case? I'm really sorry but your patch doesn't work at all. I'm not even able to start the VM. KVM process hangs and never detaches itself. No problem, my fault---I'm just back and I haven't really started again all my stuff, so the patch was not tested. This should fix it, though. Paolo diff --git a/block/iscsi.c b/block/iscsi.c index 74ada64..0b96165 100644 --- a/block/iscsi.c +++ b/block/iscsi.c @@ -247,6 +247,7 @@ iscsi_aio_writev(BlockDriverState *bs, int64_t sector_num, acb-qiov = qiov; acb-canceled = 0; +acb-bh = NULL; acb-status = -EINPROGRESS; /* XXX we should pass the iovec to write16 to avoid the extra copy */ @@ -341,6 +342,7 @@ iscsi_aio_readv(BlockDriverState *bs, int64_t sector_num, acb-qiov = qiov; acb-canceled= 0; +acb-bh = NULL; acb-status = -EINPROGRESS; acb-read_size = qemu_read_size; acb-buf = NULL; @@ -442,6 +444,7 @@ iscsi_aio_flush(BlockDriverState *bs, acb-iscsilun = iscsilun; acb-canceled = 0; +acb-bh = NULL; acb-status = -EINPROGRESS; acb-task = iscsi_synchronizecache10_task(iscsi, iscsilun-lun, @@ -494,6 +497,7 @@ iscsi_aio_discard(BlockDriverState *bs, acb-iscsilun = iscsilun; acb-canceled = 0; +acb-bh = NULL; acb-status = -EINPROGRESS; list[0].lba = sector_qemu2lun(sector_num, iscsilun); @@ -568,6 +572,7 @@ static BlockDriverAIOCB *iscsi_aio_ioctl(BlockDriverState *bs, acb-iscsilun = iscsilun; acb-canceled= 0; +acb-bh = NULL; acb-status = -EINPROGRESS; acb-buf = NULL; acb-ioh = buf;
Re: [Qemu-devel] [PATCH for-1.2? v4 1/2] envlist.c: conform to QEMU's coding style
Am 17.08.2012 20:24, schrieb Jim Meyering: From: Jim Meyering meyer...@redhat.com Convert each TAB(width-4) to equivalent spaces. Put braces around each one-line if-body. Signed-off-by: Jim Meyering meyer...@redhat.com Reviewed-by: Andreas Färber afaer...@suse.de Thanks, Andreas P.S. CC'ing linux-user folks. -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH for-1.2? v4 2/2] envlist.c: handle strdup failure
Am 17.08.2012 20:24, schrieb Jim Meyering:
From: Jim Meyering meyer...@redhat.com
Without this, envlist_to_environ may silently fail to copy all
strings into the destination buffer, and both callers would leak
any env strings allocated after a failing strdup, because the
freeing code stops at the first NULL pointer.
Signed-off-by: Jim Meyering meyer...@redhat.com
---
envlist.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/envlist.c b/envlist.c
index 230596f..cf3f2d8 100644
--- a/envlist.c
+++ b/envlist.c
@@ -245,8 +245,16 @@ envlist_to_environ(const envlist_t *envlist, size_t
*count)
}
for (entry = envlist-el_entries.lh_first; entry != NULL;
- entry = entry-ev_link.le_next) {
-*(penv++) = strdup(entry-ev_var);
+ entry = entry-ev_link.le_next, penv++) {
+*penv = strdup(entry-ev_var);
+if (*penv == NULL) {
+char **e = env;
+while (e = penv) {
+free(*e++);
+}
+free(env);
+return NULL;
+}
}
*penv = NULL; /* NULL terminate the list */
Acked-by: Andreas Färber afaer...@suse.de
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] Windows slow boot: contractor wanted
On 08/17/2012 03:36 PM, Richard Davies wrote: Hi Avi, Thanks to you and several others for offering help. We will work with Avi at first, but are grateful for all the other offers of help. We have a number of other qemu-related projects which we'd be interested in getting done, and will get in touch with these names (and anyone else who comes forward) to see if any are of interest to you. This slow boot problem is intermittent and varys in how slow the boots are, but I managed to trigger it this morning with medium slow booting (5-10 minutes) and link to the requested traces below. The host in question has 128GB RAM and dual AMD Opteron 6128 (16 cores total). It is running kernel 3.5.1 and qemu-kvm 1.1.1. In this morning's test, we have 3 guests, all booting Windows with 40GB RAM and 8 cores each (we have seen small VMs go slow as I originally said, but it is easier to trigger with big VMs): pid 15665: qemu-kvm -nodefaults -m 40960 -smp 8 -cpu host,hv_relaxed \ -vga cirrus -usbdevice tablet -vnc :99 -monitor stdio -hda test1.raw pid 15676: qemu-kvm -nodefaults -m 40960 -smp 8 -cpu host,hv_relaxed \ -vga cirrus -usbdevice tablet -vnc :98 -monitor stdio -hda test2.raw pid 15653: qemu-kvm -nodefaults -m 40960 -smp 8 -cpu host,hv_relaxed \ -vga cirrus -usbdevice tablet -vnc :97 -monitor stdio -hda test3.raw We are running with hv_relaxed since this was suggested in the previous thread, but we see intermittent slow boots with and without this flag. All 3 VMs are booting slowly for most of the attached capture, which I started after confirming the slow boots and stopped as soon as the first of them (15665) had booted. In terms of visible symptoms, the VMs are showing the Windows boot progress bar, which is moving very slowly. In top, the VMs are at 400% CPU and their resident state size (RES) memory is slowly counting up until it reaches the full VM size, at which point they finish booting. Here are the trace files: http://users.org.uk/slow-win-boot-1/ps.txt (ps auxwwwf as root) http://users.org.uk/slow-win-boot-1/top.txt (top with 2 VMs still slow) http://users.org.uk/slow-win-boot-1/trace-console.txt (running trace-cmd) http://users.org.uk/slow-win-boot-1/trace.dat (the 1.7G trace data file) http://users.org.uk/slow-win-boot-1/trace-report.txt (the 4G trace report) Please let me know if there is anything else which I can provide? There are tons of PAUSE exits indicating cpu overcommit (and indeed you are overcommitted by about 50%). What host kernel version are you running? Does this reproduce without overcommit? -- error compiling committee.c: too many arguments to function
[Qemu-devel] Big real mode use in ipxe
ipxe contains the following snippet: /* Copy ROM to image source PMM block */ pushw %es xorw%ax, %ax movw%ax, %es movl%esi, %edi xorl%esi, %esi movzbl romheader_size, %ecx shll$9, %ecx addr32 rep movsb/* PMM presence implies flat real mode */ Which copies an image to %edi, with %edi = 0x1. This is in accordance with the PMM spec: 3.2.4 Accessing Extended Memory This section specifies how clients should access extended memory blocks allocated by the PMM. When control is passed to an option ROM from a BIOS that supports PMM, the processor will be in big real mode, and Gate A20 will be disabled (segment wrap turned off). This allows access to extended memory blocks using real mode addressing. In big real mode, access to memory above 1MB can be accomplished by using a 32-bit extended index register (EDI, etc.) and setting the segment register to h. The following code example assumes that the pmmAllocate function was just called to allocate a block of extended memory, and DX:AX returned the 32-bit buffer address. ; Assume here that DX:AX contains the 32-bit address of our allocated buffer. ; Clear the DS segment register. push h pop ds ; Put the DX:AX 32-bit buffer address into EDI. mov di, dx ; Get the upper word. shl edi, 16 ; Shift it to upper EDI. mov di, ax ; Get the lower word. ; Example: clear the first four bytes of the extended memory buffer. mov [edi], h ; DS:EDI is used as the memory pointer. In a similar way, the other segment registers and 32-bit index registers can be used for extended memory accessing. So far so good. But the Intel SDM says (20.1.1): The IA-32 processors beginning with the Intel386 processor can generate 32-bit offsets using an address override prefix; however, in real-address mode, the value of a 32-bit offset may not exceed H without causing an exception. For full compatibility with Intel 286 real-address mode, pseudo-protection faults (interrupt 12 or 13) occur if a 32-bit offset is generated outside the range 0 through H. Which is exactly what happens here. My understanding of big real mode is that to achieve a segment limit != 0x, you must go into 32-bit protected mode, load a segment with a larger limit, and return into real mode without touching the segment. The next load of the segment will reset the limit to 0x. Due to bugs in both qemu tcg and kvm, limit checks are not enforced in real mode, but once this bugs are fixed, the code above will break. The PMM spec also has this to say (1.3): Big Real Mode Big Real Mode is a modified version of the processor’s real mode with the segment limits changed from 1MB to 4GB. Big real mode allows the BIOS or an Option ROM to read and write extended memory without the overhead of protected mode. The BIOS puts the processor in big real mode during POST to allow simplified access to extended memory. The processor will be in big real mode while the PMM Services are callable. This is more in line with the Intel spec, and means that the modification to %es must be avoided (and that seabios needs changes to either work in big real mode, or to put the processor back into big real mode after returning from a PMM service. The whole thing is very unfortunate, as kvm is very slow while in big real mode, on certain processors. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [ipxe-devel] Big real mode use in ipxe
On Sunday 19 Aug 2012 16:07:05 Avi Kivity wrote: Which is exactly what happens here. My understanding of big real mode is that to achieve a segment limit != 0x, you must go into 32-bit protected mode, load a segment with a larger limit, and return into real mode without touching the segment. The next load of the segment will reset the limit to 0x. Not quite. You can't return into real mode without touching the segment, since part of the process of returning to real mode is to reload the segment registers with real-mode values, and this happens _after_ setting CR0.PE=0. Whenever CR0.PE=0, loading a segment register with value N will load the literal value (N4) into the base address for that segment, without changing the limit. This is the trick that allows flat real mode (aka big real mode) to work; the limit remains at 4G even after loading the segment register with a real-mode value. (and that seabios needs changes to either work in big real mode, or to put the processor back into big real mode after returning from a PMM service. If seabios switches into protected mode when performing a PMM service, then it _must_ leave the segment limits at 4G when returning to real mode. To do otherwise will violate the PMM spec, and will break conforming clients such as iPXE. Michael
Re: [Qemu-devel] [ipxe-devel] Big real mode use in ipxe
On 08/19/2012 06:34 PM, Michael Brown wrote: On Sunday 19 Aug 2012 16:07:05 Avi Kivity wrote: Which is exactly what happens here. My understanding of big real mode is that to achieve a segment limit != 0x, you must go into 32-bit protected mode, load a segment with a larger limit, and return into real mode without touching the segment. The next load of the segment will reset the limit to 0x. Not quite. You can't return into real mode without touching the segment, since part of the process of returning to real mode is to reload the segment registers with real-mode values, and this happens _after_ setting CR0.PE=0. Whenever CR0.PE=0, loading a segment register with value N will load the literal value (N4) into the base address for that segment, without changing the limit. This is the trick that allows flat real mode (aka big real mode) to work; the limit remains at 4G even after loading the segment register with a real-mode value. So I see, from looking at the Xen source. I'll also double-check with bochs. Looks like I'll need to fix kvm not to reset the segment limit when reloading a segment in real mode. (and that seabios needs changes to either work in big real mode, or to put the processor back into big real mode after returning from a PMM service. If seabios switches into protected mode when performing a PMM service, then it _must_ leave the segment limits at 4G when returning to real mode. To do otherwise will violate the PMM spec, and will break conforming clients such as iPXE. This probably works, since iPXE works on kvm on AMD and on Intel processors with unrestricted guest support. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] Big real mode use in ipxe
On Sun, Aug 19, 2012 at 06:07:05PM +0300, Avi Kivity wrote: ipxe contains the following snippet: /* Copy ROM to image source PMM block */ pushw %es xorw%ax, %ax movw%ax, %es movl%esi, %edi xorl%esi, %esi movzbl romheader_size, %ecx shll$9, %ecx addr32 rep movsb/* PMM presence implies flat real mode */ Which copies an image to %edi, with %edi = 0x1. This is in accordance with the PMM spec: [...] So far so good. But the Intel SDM says (20.1.1): The IA-32 processors beginning with the Intel386 processor can generate 32-bit offsets using an address override prefix; however, in real-address mode, the value of a 32-bit offset may not exceed H without causing an exception. For full compatibility with Intel 286 real-address mode, pseudo-protection faults (interrupt 12 or 13) occur if a 32-bit offset is generated outside the range 0 through H. I interpretted the above to mean however, in [normal real-mode where the segment registers are set to 0x] real-address mode, the value of a 32-bit offset may not exceed H without causing an exception Which is exactly what happens here. My understanding of big real mode is that to achieve a segment limit != 0x, you must go into 32-bit protected mode, load a segment with a larger limit, and return into real mode without touching the segment. The next load of the segment will reset the limit to 0x. No, the segment limit is only changed when the protected mode bit is set and the segment register is loaded. When the protected mode bit is not set, only the segment offset changes. [...] The PMM spec also has this to say (1.3): Big Real Mode Big Real Mode is a modified version of the processor’s real mode with the segment limits changed from 1MB to 4GB. Big real mode allows the BIOS or an Option ROM to read and write extended memory without the overhead of protected mode. The BIOS puts the processor in big real mode during POST to allow simplified access to extended memory. The processor will be in big real mode while the PMM Services are callable. This is more in line with the Intel spec, and means that the modification to %es must be avoided (and that seabios needs changes to either work in big real mode, or to put the processor back into big real mode after returning from a PMM service. The SeaBIOS code is regularly used on a variety of real processors (which do enforce segment limits). This includes several different AMD processors and Intel processors. It has also been tested in the past with other manufacturers (eg, Via). We've never seen an issue with the big real mode support. The whole thing is very unfortunate, as kvm is very slow while in big real mode, on certain processors. Unfortunately, big real mode is a requirement for option roms. -Kevin
Re: [Qemu-devel] Big real mode use in ipxe
On 08/19/2012 06:44 PM, Kevin O'Connor wrote: On Sun, Aug 19, 2012 at 06:07:05PM +0300, Avi Kivity wrote: ipxe contains the following snippet: /* Copy ROM to image source PMM block */ pushw %es xorw%ax, %ax movw%ax, %es movl%esi, %edi xorl%esi, %esi movzbl romheader_size, %ecx shll$9, %ecx addr32 rep movsb/* PMM presence implies flat real mode */ Which copies an image to %edi, with %edi = 0x1. This is in accordance with the PMM spec: [...] So far so good. But the Intel SDM says (20.1.1): The IA-32 processors beginning with the Intel386 processor can generate 32-bit offsets using an address override prefix; however, in real-address mode, the value of a 32-bit offset may not exceed H without causing an exception. For full compatibility with Intel 286 real-address mode, pseudo-protection faults (interrupt 12 or 13) occur if a 32-bit offset is generated outside the range 0 through H. I interpretted the above to mean however, in [normal real-mode where the segment registers are set to 0x] real-address mode, the value of a 32-bit offset may not exceed H without causing an exception I understood it the same way. Which is exactly what happens here. My understanding of big real mode is that to achieve a segment limit != 0x, you must go into 32-bit protected mode, load a segment with a larger limit, and return into real mode without touching the segment. The next load of the segment will reset the limit to 0x. No, the segment limit is only changed when the protected mode bit is set and the segment register is loaded. When the protected mode bit is not set, only the segment offset changes. That's what I missed. I always understood a segment reload in real mode to reset the limit field, though I had no basis for it. I'll fix kvm not to do this. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [ipxe-devel] Big real mode use in ipxe
On Sun, Aug 19, 2012 at 04:34:50PM +0100, Michael Brown wrote: On Sunday 19 Aug 2012 16:07:05 Avi Kivity wrote: (and that seabios needs changes to either work in big real mode, or to put the processor back into big real mode after returning from a PMM service. If seabios switches into protected mode when performing a PMM service, then it _must_ leave the segment limits at 4G when returning to real mode. To do otherwise will violate the PMM spec, and will break conforming clients such as iPXE. SeaBIOS does switch to 32bit mode during PMM calls and does switch to 16bit big real mode (segment limits set to 4G) on return. -Kevin
Re: [Qemu-devel] [PATCH RFT 0/3] iscsi: fix NULL dereferences / races between task completion and abort
Am 19.08.2012 15:11, schrieb Paolo Bonzini: No problem, my fault---I'm just back and I haven't really started again all my stuff, so the patch was not tested. This should fix it, though. Booting works fine now. But the VM starts to hang after trying to unmap large regions. No segfault or so just not reacting anymore. Stefan
Re: [Qemu-devel] Funny -m arguments can crash
On Mon, Aug 13, 2012 at 04:56:53PM +0300, Avi Kivity wrote: IMO we need to fix CMOS reporting. (technically we shouldn't touch CMOS NVRAM at all; seabios should discover memory size via fwcfg and program it itself. But it's pointless to change it now) It would be nice to pass all values via fw_cfg instead of cmos. Using the cmos to pass valus is cumbersome. If there is some desire to specify memory to a finer granularity than 1MiB (and frankly I'm struggling to understand the desire for that), then lets pass it via fw_cfg instead of cmos. -Kevin
Re: [Qemu-devel] [PATCH v3 2/2] pc: Fix RTC CMOS info on RAM for ram_size 1MiB
On Wed, Aug 15, 2012 at 01:12:20PM +0200, Markus Armbruster wrote: pc_cmos_init() always claims 640KiB base memory, and ram_size - 1MiB extended memory. The latter can underflow to lots of extended memory. Fix both, and clean up some. Note: SeaBIOS currently requires 1MiB of RAM, and doesn't check whether it got enough. SeaBIOS (and Bochs BIOS before it) never checked cmos 0x15-0x18 for memory sizes. Thus, it has only ever supported passing memory in 1MiB chunks. If we really want to communicate fine grained memory sizes, I suggest passing an e820 like map via fw_cfg to SeaBIOS. I don't think it makes sense for SeaBIOS to read new magic cmos settings just to check if it should crash in a slightly different way. -Kevin
[Qemu-devel] [Bug 1035572] Re: Bug in Qemu User Mode
Hi,
here are the next steps what I am doing. I get the oldest qemu-0.41 version,
that I can get,
from June 2003:-).
Very interesting, the syscall.c today in Qemu 1.2.0 is build exact like that
from 2003.
And the testclone.c programm comes together with Qemu 0.41 and compiled also.
So, not so difficult to understand what is going wrong: No NPTL in Qemu from
2003,
the mistakes have been done in this very first version or in a version later.
Because I think, that Fabrice can do his own testclone programm in the very
first version, it should work.
This I am just testing,
nice to hear from you,
Dietmar
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1035572
Title:
Bug in Qemu User Mode
Status in QEMU:
New
Bug description:
Hi,
I make an interesting discovery.
My aim is to have a working qemu-i386 on Raspberry Pi.
After long searching in the dark what goes wrong with ANY Qemu version for
User Mode until today,
I find the following: The bug must be in at least one function, that the
program testclone
from the testpackage for i386 in linux-user-test-0.3 calls.
The wrong function is in the part, which enables more than one thread at the
same time, NPTL.
Funny, how I find this out: All the programs from the tests in
linux-user-test-0.3 I can now run succesfull with my new builded qemu-i386 for
Raspi.
But the program testclone does not stop after it gives out all the right
messages.
The program testclone stops on my Desktop computer with Debian Wheezy
installed.
So, the error is not in the program testclone.
So I make a look, what is going on there with strace. With strace you get
informations about all the values in the working program, here testclone.
I see, that the reason, why testclone not stops is in an infinite loop
because of
while (waitpid(pid1, status1, 0) != pid1);
while (waitpid(pid2, status2, 0) != pid2);
at its end is never fullfilled.
This is the reason for the famous error message from Qemu User Mode
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault
stack1 = malloc(STACK_SIZE);
pid1 = clone(thread1_func, stack1 + STACK_SIZE,
CLONE_VM | CLONE_FS | CLONE_FILES | SIGCHLD, hello1);
stack2 = malloc(STACK_SIZE);
pid2 = clone(thread2_func, stack2 + STACK_SIZE,
CLONE_VM | CLONE_FS | CLONE_FILES | SIGCHLD, hello2);
The error happens early in the program testclone. Strace says, it is because
no childprocess at all can be found. So, some basiccalculations in those four
lines must be done wrong from Qemu.
I think, that the adressspace for each thread is calculated wrong, or
overlapps.
Funny, it has nothing to do with the ARM processor. I get exact the same
errormessages, when I run the program testclone on my desktopcompi i386 with a
Wheezy in Qemu and then qemu-i386 testclone.
This is a good message, because it means it is an error, that belongs at
least to the i386 family but I think, every processor in Qemu User Mode is
involved, so until now NPTL does not work.
Today I make a hand by hand calculation with the source code from testclone
and compare it with the values, that Qemu User Mode give. The handcalculated
values should be the same which my
Desktop computer with Wheezy with tesclone produces, but who knows,
Dietmar
PS: I hope, that this is the right source code for testclone. Any help
is welcome:-)!
Code: Select all
#include stdlib.h
#include stdio.h
#include string.h
#include signal.h
#include unistd.h
#include inttypes.h
#include pthread.h
#include sys/wait.h
#include sched.h
int thread1_func(void *arg)
{
int i;
char buf[512];
for(i=0;i10;i++) {
snprintf(buf, sizeof(buf), thread1: %d %s\n, i, (char *)arg);
write(1, buf, strlen(buf));
usleep(100 * 1000);
}
return 0;
}
int thread2_func(void *arg)
{
int i;
char buf[512];
for(i=0;i20;i++) {
snprintf(buf, sizeof(buf), thread2: %d %s\n, i, (char *)arg);
write(1, buf, strlen(buf));
usleep(120 * 1000);
}
return 0;
}
#define STACK_SIZE 16384
void test_clone(void)
{
uint8_t *stack1, *stack2;
int pid1, pid2, status1, status2;
stack1 = malloc(STACK_SIZE);
pid1 = clone(thread1_func, stack1 + STACK_SIZE,
CLONE_VM | CLONE_FS | CLONE_FILES | SIGCHLD, hello1);
stack2 = malloc(STACK_SIZE);
pid2 = clone(thread2_func, stack2 + STACK_SIZE,
CLONE_VM | CLONE_FS | CLONE_FILES | SIGCHLD, hello2);
while (waitpid(pid1, status1, 0) != pid1);
while (waitpid(pid2, status2, 0) != pid2);
printf(status1=0x%x\n, status1);
printf(status2=0x%x\n, status2);
printf(End of clone test.\n);
}
int main(int argc, char **argv)
{
test_clone();
return 0;
}
Posts: 210
[Qemu-devel] [Bug 1035572] Re: Bug in Qemu User Mode
Yeeaah,
the first version of qemu-0.4.1 is the ONLY version of Qemu,
that runs the testclone programm without any error.
This is nice, because the structure of calling clone() in syscall.c is today
the same as in 0.4.1.
This means, the error can be fixed,
Dietmar
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1035572
Title:
Bug in Qemu User Mode
Status in QEMU:
New
Bug description:
Hi,
I make an interesting discovery.
My aim is to have a working qemu-i386 on Raspberry Pi.
After long searching in the dark what goes wrong with ANY Qemu version for
User Mode until today,
I find the following: The bug must be in at least one function, that the
program testclone
from the testpackage for i386 in linux-user-test-0.3 calls.
The wrong function is in the part, which enables more than one thread at the
same time, NPTL.
Funny, how I find this out: All the programs from the tests in
linux-user-test-0.3 I can now run succesfull with my new builded qemu-i386 for
Raspi.
But the program testclone does not stop after it gives out all the right
messages.
The program testclone stops on my Desktop computer with Debian Wheezy
installed.
So, the error is not in the program testclone.
So I make a look, what is going on there with strace. With strace you get
informations about all the values in the working program, here testclone.
I see, that the reason, why testclone not stops is in an infinite loop
because of
while (waitpid(pid1, status1, 0) != pid1);
while (waitpid(pid2, status2, 0) != pid2);
at its end is never fullfilled.
This is the reason for the famous error message from Qemu User Mode
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault
stack1 = malloc(STACK_SIZE);
pid1 = clone(thread1_func, stack1 + STACK_SIZE,
CLONE_VM | CLONE_FS | CLONE_FILES | SIGCHLD, hello1);
stack2 = malloc(STACK_SIZE);
pid2 = clone(thread2_func, stack2 + STACK_SIZE,
CLONE_VM | CLONE_FS | CLONE_FILES | SIGCHLD, hello2);
The error happens early in the program testclone. Strace says, it is because
no childprocess at all can be found. So, some basiccalculations in those four
lines must be done wrong from Qemu.
I think, that the adressspace for each thread is calculated wrong, or
overlapps.
Funny, it has nothing to do with the ARM processor. I get exact the same
errormessages, when I run the program testclone on my desktopcompi i386 with a
Wheezy in Qemu and then qemu-i386 testclone.
This is a good message, because it means it is an error, that belongs at
least to the i386 family but I think, every processor in Qemu User Mode is
involved, so until now NPTL does not work.
Today I make a hand by hand calculation with the source code from testclone
and compare it with the values, that Qemu User Mode give. The handcalculated
values should be the same which my
Desktop computer with Wheezy with tesclone produces, but who knows,
Dietmar
PS: I hope, that this is the right source code for testclone. Any help
is welcome:-)!
Code: Select all
#include stdlib.h
#include stdio.h
#include string.h
#include signal.h
#include unistd.h
#include inttypes.h
#include pthread.h
#include sys/wait.h
#include sched.h
int thread1_func(void *arg)
{
int i;
char buf[512];
for(i=0;i10;i++) {
snprintf(buf, sizeof(buf), thread1: %d %s\n, i, (char *)arg);
write(1, buf, strlen(buf));
usleep(100 * 1000);
}
return 0;
}
int thread2_func(void *arg)
{
int i;
char buf[512];
for(i=0;i20;i++) {
snprintf(buf, sizeof(buf), thread2: %d %s\n, i, (char *)arg);
write(1, buf, strlen(buf));
usleep(120 * 1000);
}
return 0;
}
#define STACK_SIZE 16384
void test_clone(void)
{
uint8_t *stack1, *stack2;
int pid1, pid2, status1, status2;
stack1 = malloc(STACK_SIZE);
pid1 = clone(thread1_func, stack1 + STACK_SIZE,
CLONE_VM | CLONE_FS | CLONE_FILES | SIGCHLD, hello1);
stack2 = malloc(STACK_SIZE);
pid2 = clone(thread2_func, stack2 + STACK_SIZE,
CLONE_VM | CLONE_FS | CLONE_FILES | SIGCHLD, hello2);
while (waitpid(pid1, status1, 0) != pid1);
while (waitpid(pid2, status2, 0) != pid2);
printf(status1=0x%x\n, status1);
printf(status2=0x%x\n, status2);
printf(End of clone test.\n);
}
int main(int argc, char **argv)
{
test_clone();
return 0;
}
Posts: 210
Joined: 04 Sep 2011 17:43
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1035572/+subscriptions
[Qemu-devel] [Bug 1035572] Re: Bug in Qemu User Mode
Thanks for doing this testing but I'm afraid it really isn't giving us
any new information. We already know clone is broken for i386 targets;
see my comment #9 in this bug.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1035572
Title:
Bug in Qemu User Mode
Status in QEMU:
New
Bug description:
Hi,
I make an interesting discovery.
My aim is to have a working qemu-i386 on Raspberry Pi.
After long searching in the dark what goes wrong with ANY Qemu version for
User Mode until today,
I find the following: The bug must be in at least one function, that the
program testclone
from the testpackage for i386 in linux-user-test-0.3 calls.
The wrong function is in the part, which enables more than one thread at the
same time, NPTL.
Funny, how I find this out: All the programs from the tests in
linux-user-test-0.3 I can now run succesfull with my new builded qemu-i386 for
Raspi.
But the program testclone does not stop after it gives out all the right
messages.
The program testclone stops on my Desktop computer with Debian Wheezy
installed.
So, the error is not in the program testclone.
So I make a look, what is going on there with strace. With strace you get
informations about all the values in the working program, here testclone.
I see, that the reason, why testclone not stops is in an infinite loop
because of
while (waitpid(pid1, status1, 0) != pid1);
while (waitpid(pid2, status2, 0) != pid2);
at its end is never fullfilled.
This is the reason for the famous error message from Qemu User Mode
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault
stack1 = malloc(STACK_SIZE);
pid1 = clone(thread1_func, stack1 + STACK_SIZE,
CLONE_VM | CLONE_FS | CLONE_FILES | SIGCHLD, hello1);
stack2 = malloc(STACK_SIZE);
pid2 = clone(thread2_func, stack2 + STACK_SIZE,
CLONE_VM | CLONE_FS | CLONE_FILES | SIGCHLD, hello2);
The error happens early in the program testclone. Strace says, it is because
no childprocess at all can be found. So, some basiccalculations in those four
lines must be done wrong from Qemu.
I think, that the adressspace for each thread is calculated wrong, or
overlapps.
Funny, it has nothing to do with the ARM processor. I get exact the same
errormessages, when I run the program testclone on my desktopcompi i386 with a
Wheezy in Qemu and then qemu-i386 testclone.
This is a good message, because it means it is an error, that belongs at
least to the i386 family but I think, every processor in Qemu User Mode is
involved, so until now NPTL does not work.
Today I make a hand by hand calculation with the source code from testclone
and compare it with the values, that Qemu User Mode give. The handcalculated
values should be the same which my
Desktop computer with Wheezy with tesclone produces, but who knows,
Dietmar
PS: I hope, that this is the right source code for testclone. Any help
is welcome:-)!
Code: Select all
#include stdlib.h
#include stdio.h
#include string.h
#include signal.h
#include unistd.h
#include inttypes.h
#include pthread.h
#include sys/wait.h
#include sched.h
int thread1_func(void *arg)
{
int i;
char buf[512];
for(i=0;i10;i++) {
snprintf(buf, sizeof(buf), thread1: %d %s\n, i, (char *)arg);
write(1, buf, strlen(buf));
usleep(100 * 1000);
}
return 0;
}
int thread2_func(void *arg)
{
int i;
char buf[512];
for(i=0;i20;i++) {
snprintf(buf, sizeof(buf), thread2: %d %s\n, i, (char *)arg);
write(1, buf, strlen(buf));
usleep(120 * 1000);
}
return 0;
}
#define STACK_SIZE 16384
void test_clone(void)
{
uint8_t *stack1, *stack2;
int pid1, pid2, status1, status2;
stack1 = malloc(STACK_SIZE);
pid1 = clone(thread1_func, stack1 + STACK_SIZE,
CLONE_VM | CLONE_FS | CLONE_FILES | SIGCHLD, hello1);
stack2 = malloc(STACK_SIZE);
pid2 = clone(thread2_func, stack2 + STACK_SIZE,
CLONE_VM | CLONE_FS | CLONE_FILES | SIGCHLD, hello2);
while (waitpid(pid1, status1, 0) != pid1);
while (waitpid(pid2, status2, 0) != pid2);
printf(status1=0x%x\n, status1);
printf(status2=0x%x\n, status2);
printf(End of clone test.\n);
}
int main(int argc, char **argv)
{
test_clone();
return 0;
}
Posts: 210
Joined: 04 Sep 2011 17:43
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1035572/+subscriptions
[Qemu-devel] [Bug 1035572] Re: Bug in Qemu User Mode
didi2@linux:~ strace -f qemu testclonenonptl
execve(/usr/local/bin/qemu, [qemu, testclonenonptl], [/* 67 vars */]) = 0
uname({sys=Linux, node=linux, ...}) = 0
brk(0) = 0x80463540
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40019000
open(/etc/ld.so.preload, O_RDONLY)= -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=102185, ...}) = 0
old_mmap(NULL, 102185, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4001a000
close(3)= 0
open(/lib/i686/libm.so.6, O_RDONLY) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 5\0\000..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=183008, ...}) = 0
old_mmap(NULL, 142672, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40033000
old_mmap(0x40055000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0x21000) = 0x40055000
close(3)= 0
open(/lib/i686/libc.so.6, O_RDONLY) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320]\1..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1461208, ...}) = 0
old_mmap(NULL, 1256644, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40056000
old_mmap(0x40182000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0x12c000) = 0x40182000
old_mmap(0x40187000, 7364, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40187000
close(3)= 0
mprotect(0x8000, 327680, PROT_READ|PROT_WRITE) = 0
mprotect(0x8000, 327680, PROT_READ|PROT_EXEC) = 0
munmap(0x4001a000, 102185) = 0
brk(0) = 0x80463540
brk(0x80484540) = 0x80484540
brk(0) = 0x80484540
brk(0x80485000) = 0x80485000
open(/usr/local/qemu-i386, O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = -1
ENOENT (No such file or directory)
open(testclonenonptl, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0755, st_size=9503, ...}) = 0
geteuid32() = 500
getegid32() = 100
lseek(3, 0, SEEK_SET) = 0
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0\360\203..., 128) = 128
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x4001a000
lseek(3, 52, SEEK_SET) = 52
read(3, \6\0\0\0004\0\0\0004\200\4\0104\200\4\10\300\0\0\0\300..., 192) = 192
lseek(3, 244, SEEK_SET) = 244
read(3, /lib/ld-linux.so.2\0, 19) = 19
open(/lib/ld-linux.so.2, O_RDONLY)= 4
lseek(4, 0, SEEK_SET) = 0
read(4, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20\f\0..., 128) = 128
mmap2(NULL, 528384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40189000
mprotect(0x40209000, 4096, PROT_NONE) = 0
munmap(0x4001a000, 4096)= 0
mmap2(0x8048000, 4096, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0) = 0x8048000
mmap2(0x8049000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0) = 0x8049000
lseek(4, 52, SEEK_SET) = 52
read(4, \1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\354s\1\0\354s\1\0\5\0..., 128) = 128
mmap2(NULL, 33554432, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4020a000
mmap2(0x4020a000, 98304, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0) = 0x4020a000
mmap2(0x40222000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x17) = 0x40222000
close(4)= 0
close(4)= -1 EBADF (Bad file descriptor)
close(3)= 0
getuid32() = 500
geteuid32() = 500
getgid32() = 100
getegid32() = 100
rt_sigaction(SIGHUP, {0x800276a0, ~[], SA_RESTORER|SA_SIGINFO, 0x4007faa0},
NULL, 8) = 0
rt_sigaction(SIGINT, {0x800276a0, ~[], SA_RESTORER|SA_SIGINFO, 0x4007faa0},
NULL, 8) = 0
rt_sigaction(SIGQUIT, {0x800276a0, ~[], SA_RESTORER|SA_SIGINFO, 0x4007faa0},
NULL, 8) = 0
rt_sigaction(SIGILL, {0x800276a0, ~[], SA_RESTORER|SA_SIGINFO, 0x4007faa0},
NULL, 8) = 0
rt_sigaction(SIGTRAP, {0x800276a0, ~[], SA_RESTORER|SA_SIGINFO, 0x4007faa0},
NULL, 8) = 0
rt_sigaction(SIGABRT, {0x800276a0, ~[], SA_RESTORER|SA_SIGINFO, 0x4007faa0},
NULL, 8) = 0
rt_sigaction(SIGBUS, {0x800276a0, ~[], SA_RESTORER|SA_SIGINFO, 0x4007faa0},
NULL, 8) = 0
rt_sigaction(SIGFPE, {0x800276a0, ~[], SA_RESTORER|SA_SIGINFO, 0x4007faa0},
NULL, 8) = 0
rt_sigaction(SIGKILL, {0x800276a0, ~[], SA_RESTORER|SA_SIGINFO, 0x4007faa0},
NULL, 8) = -1 EINVAL (Invalid argument)
rt_sigaction(SIGUSR1, {0x800276a0, ~[], SA_RESTORER|SA_SIGINFO, 0x4007faa0},
NULL, 8) = 0
rt_sigaction(SIGSEGV, {0x800276a0, ~[], SA_RESTORER|SA_SIGINFO, 0x4007faa0},
NULL, 8) = 0
rt_sigaction(SIGUSR2, {0x800276a0, ~[], SA_RESTORER|SA_SIGINFO, 0x4007faa0},
[Qemu-devel] [PATCH 0/5 v2] cpu: make a child of DeviceState
this is th 3rd approach to make CPU a child of DeviceState for both kinds of targets *-user and *-softmmu. It seems with current state of qemu it doesn't take too much effort to make it compile. Please check if it doesn't break something on other targets/archs/hosts than i386. what's tested: - compile tested building all targets on FC17x64 host. - briefly tested i386 user and softmmu targets Anthony Liguori (1): qdev: split up header so it can be used in cpu.h Igor Mammedov (4): move qemu_irq typedef out of cpu-common.h qapi-types.h doesn't really need to include qemu-common.h cleanup error.h, included qapi-types.h aready has stdbool.h make CPU a child of DeviceState error.h |1 - hw/arm-misc.h |1 + hw/bt.h |2 + hw/devices.h |2 + hw/irq.h |2 + hw/mc146818rtc.c |1 + hw/omap.h |1 + hw/qdev-addr.c|1 + hw/qdev-core.h| 240 hw/qdev-monitor.h | 16 ++ hw/qdev-properties.c |1 + hw/qdev-properties.h | 128 + hw/qdev.c |1 + hw/qdev.h | 371 + hw/soc_dma.h |1 + hw/xen.h |1 + include/qemu/cpu.h|6 +- qemu-common.h |1 - scripts/qapi-types.py |2 +- sysemu.h |1 + 20 files changed, 407 insertions(+), 373 deletions(-) create mode 100644 hw/qdev-core.h create mode 100644 hw/qdev-monitor.h create mode 100644 hw/qdev-properties.h
[Qemu-devel] [PATCH 1/5] move qemu_irq typedef out of cpu-common.h
it's necessary for making CPU child of DEVICE without
causing circular header deps.
Signed-off-by: Igor Mammedov imamm...@redhat.com
---
hw/arm-misc.h |1 +
hw/bt.h |2 ++
hw/devices.h |2 ++
hw/irq.h |2 ++
hw/omap.h |1 +
hw/soc_dma.h |1 +
hw/xen.h |1 +
qemu-common.h |1 -
sysemu.h |1 +
9 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/hw/arm-misc.h b/hw/arm-misc.h
index bdd8fec..b13aa59 100644
--- a/hw/arm-misc.h
+++ b/hw/arm-misc.h
@@ -12,6 +12,7 @@
#define ARM_MISC_H 1
#include memory.h
+#include hw/irq.h
/* The CPU is also modeled as an interrupt controller. */
#define ARM_PIC_CPU_IRQ 0
diff --git a/hw/bt.h b/hw/bt.h
index a48b8d4..ebf6a37 100644
--- a/hw/bt.h
+++ b/hw/bt.h
@@ -23,6 +23,8 @@
* along with this program; if not, see http://www.gnu.org/licenses/.
*/
+#include hw/irq.h
+
/* BD Address */
typedef struct {
uint8_t b[6];
diff --git a/hw/devices.h b/hw/devices.h
index 1a55c1e..c60bcab 100644
--- a/hw/devices.h
+++ b/hw/devices.h
@@ -1,6 +1,8 @@
#ifndef QEMU_DEVICES_H
#define QEMU_DEVICES_H
+#include hw/irq.h
+
/* ??? Not all users of this file can include cpu-common.h. */
struct MemoryRegion;
diff --git a/hw/irq.h b/hw/irq.h
index 56c55f0..1339a3a 100644
--- a/hw/irq.h
+++ b/hw/irq.h
@@ -3,6 +3,8 @@
/* Generic IRQ/GPIO pin infrastructure. */
+typedef struct IRQState *qemu_irq;
+
typedef void (*qemu_irq_handler)(void *opaque, int n, int level);
void qemu_set_irq(qemu_irq irq, int level);
diff --git a/hw/omap.h b/hw/omap.h
index 413851b..8b08462 100644
--- a/hw/omap.h
+++ b/hw/omap.h
@@ -19,6 +19,7 @@
#ifndef hw_omap_h
#include memory.h
# define hw_omap_h omap.h
+#include hw/irq.h
# define OMAP_EMIFS_BASE 0x
# define OMAP2_Q0_BASE 0x
diff --git a/hw/soc_dma.h b/hw/soc_dma.h
index 904b26c..e386ace 100644
--- a/hw/soc_dma.h
+++ b/hw/soc_dma.h
@@ -19,6 +19,7 @@
*/
#include memory.h
+#include hw/irq.h
struct soc_dma_s;
struct soc_dma_ch_s;
diff --git a/hw/xen.h b/hw/xen.h
index e5926b7..ff11dfd 100644
--- a/hw/xen.h
+++ b/hw/xen.h
@@ -8,6 +8,7 @@
*/
#include inttypes.h
+#include hw/irq.h
#include qemu-common.h
/* xen-machine.c */
diff --git a/qemu-common.h b/qemu-common.h
index e5c2bcd..6677a30 100644
--- a/qemu-common.h
+++ b/qemu-common.h
@@ -273,7 +273,6 @@ typedef struct PCIEPort PCIEPort;
typedef struct PCIESlot PCIESlot;
typedef struct MSIMessage MSIMessage;
typedef struct SerialState SerialState;
-typedef struct IRQState *qemu_irq;
typedef struct PCMCIACardState PCMCIACardState;
typedef struct MouseTransformInfo MouseTransformInfo;
typedef struct uWireSlave uWireSlave;
diff --git a/sysemu.h b/sysemu.h
index 65552ac..f765821 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -9,6 +9,7 @@
#include qapi-types.h
#include notify.h
#include main-loop.h
+#include hw/irq.h
/* vl.c */
--
1.7.1
[Qemu-devel] [PATCH 4/5] cleanup error.h, included qapi-types.h aready has stdbool.h
Signed-off-by: Igor Mammedov imamm...@redhat.com --- error.h |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/error.h b/error.h index 96fc203..643a372 100644 --- a/error.h +++ b/error.h @@ -14,7 +14,6 @@ #include compiler.h #include qapi-types.h -#include stdbool.h /** * A class representing internal errors within QEMU. An error has a ErrorClass -- 1.7.1
[Qemu-devel] [PATCH 5/5] make CPU a child of DeviceState
Signed-off-by: Igor Mammedov imamm...@redhat.com
---
include/qemu/cpu.h |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/qemu/cpu.h b/include/qemu/cpu.h
index ad706a6..ac44057 100644
--- a/include/qemu/cpu.h
+++ b/include/qemu/cpu.h
@@ -20,7 +20,7 @@
#ifndef QEMU_CPU_H
#define QEMU_CPU_H
-#include qemu/object.h
+#include hw/qdev-core.h
#include qemu-thread.h
/**
@@ -46,7 +46,7 @@ typedef struct CPUState CPUState;
*/
typedef struct CPUClass {
/* private */
-ObjectClass parent_class;
+DeviceClass parent_class;
/* public */
void (*reset)(CPUState *cpu);
@@ -59,7 +59,7 @@ typedef struct CPUClass {
*/
struct CPUState {
/* private */
-Object parent_obj;
+DeviceState parent_obj;
/* public */
struct QemuThread *thread;
--
1.7.1
[Qemu-devel] [PATCH 3/5] qapi-types.h doesn't really need to include qemu-common.h
needed to prevent build breakage when CPU becomes a child of DeviceState
Signed-off-by: Igor Mammedov imamm...@redhat.com
---
scripts/qapi-types.py |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/scripts/qapi-types.py b/scripts/qapi-types.py
index cf601ae..f34addb 100644
--- a/scripts/qapi-types.py
+++ b/scripts/qapi-types.py
@@ -263,7 +263,7 @@ fdecl.write(mcgen('''
#ifndef %(guard)s
#define %(guard)s
-#include qemu-common.h
+#include stdbool.h
''',
guard=guardname(h_file)))
--
1.7.1
[Qemu-devel] [PATCH 2/5] qdev: split up header so it can be used in cpu.h
From: Anthony Liguori aligu...@us.ibm.com
Header file dependency is a frickin' nightmare right now. cpu.h tends to get
included in our 'include everything' header files but qdev also needs to include
those headers mainly for qdev-properties since it knows about CharDriverState
and friends.
We can solve this for now by splitting out qdev.h along the same lines that we
previously split the C file. Then cpu.h just needs to include qdev-core.h
v1-v2:
move qemu_irq typedef out of this patch into a separate one with an additional
cleanup of headers to fix build breakage
Signed-off-by: Anthony Liguori aligu...@us.ibm.com
Signed-off-by: Igor Mammedov imamm...@redhat.com
---
hw/mc146818rtc.c |1 +
hw/qdev-addr.c |1 +
hw/qdev-core.h | 240
hw/qdev-monitor.h| 16 ++
hw/qdev-properties.c |1 +
hw/qdev-properties.h | 128 +
hw/qdev.c|1 +
hw/qdev.h| 371 +-
8 files changed, 392 insertions(+), 367 deletions(-)
create mode 100644 hw/qdev-core.h
create mode 100644 hw/qdev-monitor.h
create mode 100644 hw/qdev-properties.h
diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
index 3777f85..3780617 100644
--- a/hw/mc146818rtc.c
+++ b/hw/mc146818rtc.c
@@ -25,6 +25,7 @@
#include qemu-timer.h
#include sysemu.h
#include mc146818rtc.h
+#include qapi/qapi-visit-core.h
#ifdef TARGET_I386
#include apic.h
diff --git a/hw/qdev-addr.c b/hw/qdev-addr.c
index b711b6b..5b5d38f 100644
--- a/hw/qdev-addr.c
+++ b/hw/qdev-addr.c
@@ -1,6 +1,7 @@
#include qdev.h
#include qdev-addr.h
#include targphys.h
+#include qapi/qapi-visit-core.h
/* --- target physical address --- */
diff --git a/hw/qdev-core.h b/hw/qdev-core.h
new file mode 100644
index 000..ca205fc
--- /dev/null
+++ b/hw/qdev-core.h
@@ -0,0 +1,240 @@
+#ifndef QDEV_CORE_H
+#define QDEV_CORE_H
+
+#include qemu-queue.h
+#include qemu-option.h
+#include qemu/object.h
+#include hw/irq.h
+#include error.h
+
+typedef struct Property Property;
+
+typedef struct PropertyInfo PropertyInfo;
+
+typedef struct CompatProperty CompatProperty;
+
+typedef struct BusState BusState;
+
+typedef struct BusClass BusClass;
+
+enum DevState {
+DEV_STATE_CREATED = 1,
+DEV_STATE_INITIALIZED,
+};
+
+enum {
+DEV_NVECTORS_UNSPECIFIED = -1,
+};
+
+#define TYPE_DEVICE device
+#define DEVICE(obj) OBJECT_CHECK(DeviceState, (obj), TYPE_DEVICE)
+#define DEVICE_CLASS(klass) OBJECT_CLASS_CHECK(DeviceClass, (klass),
TYPE_DEVICE)
+#define DEVICE_GET_CLASS(obj) OBJECT_GET_CLASS(DeviceClass, (obj), TYPE_DEVICE)
+
+typedef int (*qdev_initfn)(DeviceState *dev);
+typedef int (*qdev_event)(DeviceState *dev);
+typedef void (*qdev_resetfn)(DeviceState *dev);
+
+struct VMStateDescription;
+
+typedef struct DeviceClass {
+ObjectClass parent_class;
+
+const char *fw_name;
+const char *desc;
+Property *props;
+int no_user;
+
+/* callbacks */
+void (*reset)(DeviceState *dev);
+
+/* device state */
+const struct VMStateDescription *vmsd;
+
+/* Private to qdev / bus. */
+qdev_initfn init;
+qdev_event unplug;
+qdev_event exit;
+const char *bus_type;
+} DeviceClass;
+
+/* This structure should not be accessed directly. We declare it here
+ so that it can be embedded in individual device state structures. */
+struct DeviceState {
+Object parent_obj;
+
+const char *id;
+enum DevState state;
+struct QemuOpts *opts;
+int hotplugged;
+BusState *parent_bus;
+int num_gpio_out;
+qemu_irq *gpio_out;
+int num_gpio_in;
+qemu_irq *gpio_in;
+QLIST_HEAD(, BusState) child_bus;
+int num_child_bus;
+int instance_id_alias;
+int alias_required_for_version;
+};
+
+/*
+ * This callback is used to create Open Firmware device path in accordance with
+ * OF spec http://forthworks.com/standards/of1275.pdf. Indicidual bus bindings
+ * can be found here http://playground.sun.com/1275/bindings/.
+ */
+
+#define TYPE_BUS bus
+#define BUS(obj) OBJECT_CHECK(BusState, (obj), TYPE_BUS)
+#define BUS_CLASS(klass) OBJECT_CLASS_CHECK(BusClass, (klass), TYPE_BUS)
+#define BUS_GET_CLASS(obj) OBJECT_GET_CLASS(BusClass, (obj), TYPE_BUS)
+
+struct BusClass {
+ObjectClass parent_class;
+
+/* FIXME first arg should be BusState */
+void (*print_dev)(Monitor *mon, DeviceState *dev, int indent);
+char *(*get_dev_path)(DeviceState *dev);
+char *(*get_fw_dev_path)(DeviceState *dev);
+int (*reset)(BusState *bus);
+};
+
+typedef struct BusChild {
+DeviceState *child;
+int index;
+QTAILQ_ENTRY(BusChild) sibling;
+} BusChild;
+
+/**
+ * BusState:
+ * @qom_allocated: Indicates whether the object was allocated by QOM.
+ * @glib_allocated: Indicates whether the object was initialized in-place
+ * yet is expected to be freed with g_free().
+ */
+struct BusState {
+Object obj;
+DeviceState *parent;
+const char *name;
+int
[Qemu-devel] KVM internal error. Suberror: 1 - emulation failure for FreeDOS 7.2
Hi Guys, I was just doing some testing and decided to run Free-DOS under qemu-kvm 1.1.1 under kernel 3.0.1 (I know it's old). I downloaded the floppy disk image (1.44M) from the Qemu Testing page here: http://wiki.qemu.org/Testing Then I ran: qemu-kvm -fda odin1440.img Just press enter on the default option, then at the C:\ prompt type help, e.g. C:\help -enter- This always results in: KVM internal error. Suberror: 1 emulation failure EAX=0300 EBX= ECX= EDX= ESI=00c8 EDI=ffd6 EBP= ESP=d890 EIP=000192af EFL=0046 [---Z-P-] CPL=3 II=0 A20=1 SMM=0 HLT=0 ES =ff26 000ff260 f300 CS =f61a 000f61a0 f300 SS =064e 64e0 f300 DS =0040 0400 f300 FS = 9300 GS = 9300 LDT= 8200 TR = 8b00 GDT= 26a0 0018 IDT= 03ff CR0=0010 CR2= CR3= CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER= Code=09 0e 79 00 00 4b 45 59 42 52 44 32 20 53 59 53 20 00 03 19 56 12 33 56 33 00 00 80 12 4f 33 45 09 8b 59 00 00 4e 41 4e 53 49 20 20 20 53 59 53 00 00 The above is reproducible 100% of the time (at least for me). Given that this image is an actual example on the Qemu wiki, I would expect it to work. Albert
Re: [Qemu-devel] [RFC v0] HACK: qom: object_property_set: abort on failure
On Tue, Aug 14, 2012 at 10:50 PM, Anthony Liguori aligu...@us.ibm.com wrote:
Peter A. G. Crosthwaite peter.crosthwa...@petalogix.com writes:
Hi All. A couple of times now ive had debug issues due to silent failure of
object_property_set. This function silently fails if the requested property
does not exist for the target object. To trap this error I applied the patch
below to my tree, but I am assuming that this is not mergeable as is as im
guessing there are clients out there that are speculatively trying to set
props.
Could someone confirm the expected policy here? is setting a non-existant
property supposed to be a no-op (as it currently is) or should it fail
gracefully?
Are you calling set via object_property_set_[str,int,bool,...]?
object_propert_set_link()
Why don't you add a terminal error to those functions if setting fails and
errp
is NULL.
That all works. Thanks for the help.
Do we want no consider adding no_fail() versions of these functions
though? It could get tedious is machine models have to have an
assertion call after every object property set just to check the
property exists. Here's my code as it stands:
Error *errp = NULL;
object_property_set_link(OBJECT(dev), OBJECT(cpus[0]), cpu0, errp);
assert_no_error(errp);
Regards,
Peter
Regards,
Anthony Liguori
Whats the best meachinism for creating a no_fail version of
object_property_set,
for the 90% case where a non-existant property is an error in machine model
development?
Signed-off-by: Peter A. G. Crosthwaite peter.crosthwa...@petalogix.com
---
qom/object.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/qom/object.c b/qom/object.c
index a552be2..6e875a8 100644
--- a/qom/object.c
+++ b/qom/object.c
@@ -687,7 +687,7 @@ void object_property_set(Object *obj, Visitor *v, const
char *name,
{
ObjectProperty *prop = object_property_find(obj, name, errp);
if (prop == NULL) {
-return;
+abort();
}
if (!prop-set) {
--
1.7.0.4
Re: [Qemu-devel] [PATCH] i2c: factor out VMSD to parent class
On Tue, Aug 14, 2012 at 6:46 PM, Peter Maydell peter.mayd...@linaro.org wrote: On 14 August 2012 09:27, Juan Quintela quint...@redhat.com wrote: Peter A. G. Crosthwaite peter.crosthwa...@petalogix.com wrote: Hi All. PMM raised a query on a recent series of mine (the SSI series) about handling VMSD for devices which define state at multiple levels of the QOM heirachy. - If you ask me, I would very much preffer something like PCI devices, where the 1st field of any specific device is the i2c part. This would achieve two things: * all i2c devices would have the common fields at the beggining * we sent the data for one device in one go, so we will never had trouble making sure that both devices arrive at the same time, in the right order, etc. - I guess there is same reasy why you want to split the device state, it could be on the other series where I haven't read it though. So this is exactly what I have done in the SSI. Correct me if I am wrong but it is the same setup as PCI where the VMSTATE_PCI_DEVICE (VMSTATE_SSI_SLAVE in my case) is the first field. All I need to do is bump version numbers? Regards, Peter Really I'm just trying to get clarification on how class hierarchies should handle vmstate. At the moment any device which is a subclass of i2c has a VMSTATE_I2C_SLAVE field corresponding to the element in its struct which is its parent object. This seems a bit odd because surely the parent class should be responsible for its own save/load? Yes I agree. Means you have to define the super class in two places rather than one (one in the class definition and one in the VMSD). The problem is if people stick to the guns over backwards compatibility then this proposed cleanup will never happen. So unless we can fix it globally and bite the bullet on a pritty much a global version number bump, then we might as well stick with the current system for the sake of consistency rather than PCI and I2C working one way and SSI using something completely different. I'm also not sure we do this consistently through the whole QOM hierarchy. Ditto on getting consistency going, someone is going to have to sign off on a backwards incompatibility. Regards, Peter So what I'm after is not necessarily a patch so much as a decision about which way this should be handled. This would probably be good to put in a section of Anthony's QOM style guide... -- PMM
Re: [Qemu-devel] [PATCH 1/5] move qemu_irq typedef out of cpu-common.h
Am 20.08.2012 01:39, schrieb Igor Mammedov:
it's necessary for making CPU child of DEVICE without
causing circular header deps.
Signed-off-by: Igor Mammedov imamm...@redhat.com
---
hw/arm-misc.h |1 +
hw/bt.h |2 ++
hw/devices.h |2 ++
hw/irq.h |2 ++
hw/omap.h |1 +
hw/soc_dma.h |1 +
hw/xen.h |1 +
qemu-common.h |1 -
sysemu.h |1 +
9 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/hw/arm-misc.h b/hw/arm-misc.h
index bdd8fec..b13aa59 100644
--- a/hw/arm-misc.h
+++ b/hw/arm-misc.h
@@ -12,6 +12,7 @@
#define ARM_MISC_H 1
#include memory.h
+#include hw/irq.h
/* The CPU is also modeled as an interrupt controller. */
#define ARM_PIC_CPU_IRQ 0
diff --git a/hw/bt.h b/hw/bt.h
index a48b8d4..ebf6a37 100644
--- a/hw/bt.h
+++ b/hw/bt.h
@@ -23,6 +23,8 @@
* along with this program; if not, see http://www.gnu.org/licenses/.
*/
+#include hw/irq.h
+
/* BD Address */
typedef struct {
uint8_t b[6];
diff --git a/hw/devices.h b/hw/devices.h
index 1a55c1e..c60bcab 100644
--- a/hw/devices.h
+++ b/hw/devices.h
@@ -1,6 +1,8 @@
#ifndef QEMU_DEVICES_H
#define QEMU_DEVICES_H
+#include hw/irq.h
+
/* ??? Not all users of this file can include cpu-common.h. */
struct MemoryRegion;
diff --git a/hw/irq.h b/hw/irq.h
index 56c55f0..1339a3a 100644
--- a/hw/irq.h
+++ b/hw/irq.h
@@ -3,6 +3,8 @@
/* Generic IRQ/GPIO pin infrastructure. */
+typedef struct IRQState *qemu_irq;
+
typedef void (*qemu_irq_handler)(void *opaque, int n, int level);
void qemu_set_irq(qemu_irq irq, int level);
diff --git a/hw/omap.h b/hw/omap.h
index 413851b..8b08462 100644
--- a/hw/omap.h
+++ b/hw/omap.h
@@ -19,6 +19,7 @@
#ifndef hw_omap_h
#include memory.h
# define hw_omap_homap.h
+#include hw/irq.h
# define OMAP_EMIFS_BASE 0x
# define OMAP2_Q0_BASE0x
diff --git a/hw/soc_dma.h b/hw/soc_dma.h
index 904b26c..e386ace 100644
--- a/hw/soc_dma.h
+++ b/hw/soc_dma.h
@@ -19,6 +19,7 @@
*/
#include memory.h
+#include hw/irq.h
struct soc_dma_s;
struct soc_dma_ch_s;
diff --git a/hw/xen.h b/hw/xen.h
index e5926b7..ff11dfd 100644
--- a/hw/xen.h
+++ b/hw/xen.h
@@ -8,6 +8,7 @@
*/
#include inttypes.h
+#include hw/irq.h
#include qemu-common.h
/* xen-machine.c */
diff --git a/qemu-common.h b/qemu-common.h
index e5c2bcd..6677a30 100644
--- a/qemu-common.h
+++ b/qemu-common.h
@@ -273,7 +273,6 @@ typedef struct PCIEPort PCIEPort;
typedef struct PCIESlot PCIESlot;
typedef struct MSIMessage MSIMessage;
typedef struct SerialState SerialState;
-typedef struct IRQState *qemu_irq;
typedef struct PCMCIACardState PCMCIACardState;
typedef struct MouseTransformInfo MouseTransformInfo;
typedef struct uWireSlave uWireSlave;
Just move the declaration of qemu_irq to the beginning of qemu-common.h
and leave the rest of files untouched. That also fixes the circular
dependency.
I already have a patch that does this, so you can integrate it in your
series
instead of this one.
diff --git a/sysemu.h b/sysemu.h
index 65552ac..f765821 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -9,6 +9,7 @@
#include qapi-types.h
#include notify.h
#include main-loop.h
+#include hw/irq.h
/* vl.c */
[Qemu-devel] [PATCH] qemu-common: Declare qemu_irq earlier
This allows using qemu_irq in the target specific cpu.h. Signed-off-by: Stefan Weil s...@weilnetz.de --- qemu-common.h |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/qemu-common.h b/qemu-common.h index 74a99d3..88a515e 100644 --- a/qemu-common.h +++ b/qemu-common.h @@ -19,6 +19,8 @@ struct Monitor; typedef struct Monitor Monitor; typedef struct MigrationParams MigrationParams; +typedef struct IRQState *qemu_irq; + /* we put basic includes here to avoid repeating them in device drivers */ #include stdlib.h #include stdio.h @@ -276,7 +278,6 @@ typedef struct PCIEPort PCIEPort; typedef struct PCIESlot PCIESlot; typedef struct MSIMessage MSIMessage; typedef struct SerialState SerialState; -typedef struct IRQState *qemu_irq; typedef struct PCMCIACardState PCMCIACardState; typedef struct MouseTransformInfo MouseTransformInfo; typedef struct uWireSlave uWireSlave; -- 1.7.0.4
[Qemu-devel] [PATCH v7 5/6] add the QKeyCode enum and the key_defs table
key_defs[] in monitor.c is a mapping table of keys and keycodes,
this patch added a QKeyCode enum and a new key_defs table,
key's index in the enmu is same as keycode's index in new key_defs[].
And added two help functions to convert key/code to index of mapping
table, those functions will return Q_KEY_CODE_MAX if the code/key is
invalid.
'key_defs' was dropped from the monitor, monitor functions were
changed to access key_defs directly.
Signed-off-by: Amos Kong ak...@redhat.com
---
console.h|6 ++
input.c | 186 ++
monitor.c| 183 +++-
qapi-schema.json | 26
4 files changed, 229 insertions(+), 172 deletions(-)
diff --git a/console.h b/console.h
index 4334db5..7934b11 100644
--- a/console.h
+++ b/console.h
@@ -6,6 +6,7 @@
#include notify.h
#include monitor.h
#include trace.h
+#include qapi-types.h
/* keyboard/mouse support */
@@ -397,4 +398,9 @@ static inline int vnc_display_pw_expire(DisplayState *ds,
time_t expires)
/* curses.c */
void curses_display_init(DisplayState *ds, int full_screen);
+/* input.c */
+extern const int key_defs[];
+int index_from_key(const char *key);
+int index_from_keycode(int code);
+
#endif
diff --git a/input.c b/input.c
index 6968b31..5630cb1 100644
--- a/input.c
+++ b/input.c
@@ -37,6 +37,192 @@ static QTAILQ_HEAD(, QEMUPutMouseEntry) mouse_handlers =
static NotifierList mouse_mode_notifiers =
NOTIFIER_LIST_INITIALIZER(mouse_mode_notifiers);
+const int key_defs[] = {
+[Q_KEY_CODE_SHIFT] = 0x2a,
+[Q_KEY_CODE_SHIFT_R] = 0x36,
+
+[Q_KEY_CODE_ALT] = 0x38,
+[Q_KEY_CODE_ALT_R] = 0xb8,
+[Q_KEY_CODE_ALTGR] = 0x64,
+[Q_KEY_CODE_ALTGR_R] = 0xe4,
+[Q_KEY_CODE_CTRL] = 0x1d,
+[Q_KEY_CODE_CTRL_R] = 0x9d,
+
+[Q_KEY_CODE_MENU] = 0xdd,
+
+[Q_KEY_CODE_ESC] = 0x01,
+
+[Q_KEY_CODE_1] = 0x02,
+[Q_KEY_CODE_2] = 0x03,
+[Q_KEY_CODE_3] = 0x04,
+[Q_KEY_CODE_4] = 0x05,
+[Q_KEY_CODE_5] = 0x06,
+[Q_KEY_CODE_6] = 0x07,
+[Q_KEY_CODE_7] = 0x08,
+[Q_KEY_CODE_8] = 0x09,
+[Q_KEY_CODE_9] = 0x0a,
+[Q_KEY_CODE_0] = 0x0b,
+[Q_KEY_CODE_MINUS] = 0x0c,
+[Q_KEY_CODE_EQUAL] = 0x0d,
+[Q_KEY_CODE_BACKSPACE] = 0x0e,
+
+[Q_KEY_CODE_TAB] = 0x0f,
+[Q_KEY_CODE_Q] = 0x10,
+[Q_KEY_CODE_W] = 0x11,
+[Q_KEY_CODE_E] = 0x12,
+[Q_KEY_CODE_R] = 0x13,
+[Q_KEY_CODE_T] = 0x14,
+[Q_KEY_CODE_Y] = 0x15,
+[Q_KEY_CODE_U] = 0x16,
+[Q_KEY_CODE_I] = 0x17,
+[Q_KEY_CODE_O] = 0x18,
+[Q_KEY_CODE_P] = 0x19,
+[Q_KEY_CODE_BRACKET_LEFT] = 0x1a,
+[Q_KEY_CODE_BRACKET_RIGHT] = 0x1b,
+[Q_KEY_CODE_RET] = 0x1c,
+
+[Q_KEY_CODE_A] = 0x1e,
+[Q_KEY_CODE_S] = 0x1f,
+[Q_KEY_CODE_D] = 0x20,
+[Q_KEY_CODE_F] = 0x21,
+[Q_KEY_CODE_G] = 0x22,
+[Q_KEY_CODE_H] = 0x23,
+[Q_KEY_CODE_J] = 0x24,
+[Q_KEY_CODE_K] = 0x25,
+[Q_KEY_CODE_L] = 0x26,
+[Q_KEY_CODE_SEMICOLON] = 0x27,
+[Q_KEY_CODE_APOSTROPHE] = 0x28,
+[Q_KEY_CODE_GRAVE_ACCENT] = 0x29,
+
+[Q_KEY_CODE_BACKSLASH] = 0x2b,
+[Q_KEY_CODE_Z] = 0x2c,
+[Q_KEY_CODE_X] = 0x2d,
+[Q_KEY_CODE_C] = 0x2e,
+[Q_KEY_CODE_V] = 0x2f,
+[Q_KEY_CODE_B] = 0x30,
+[Q_KEY_CODE_N] = 0x31,
+[Q_KEY_CODE_M] = 0x32,
+[Q_KEY_CODE_COMMA] = 0x33,
+[Q_KEY_CODE_DOT] = 0x34,
+[Q_KEY_CODE_SLASH] = 0x35,
+
+[Q_KEY_CODE_ASTERISK] = 0x37,
+
+[Q_KEY_CODE_SPC] = 0x39,
+[Q_KEY_CODE_CAPS_LOCK] = 0x3a,
+[Q_KEY_CODE_F1] = 0x3b,
+[Q_KEY_CODE_F2] = 0x3c,
+[Q_KEY_CODE_F3] = 0x3d,
+[Q_KEY_CODE_F4] = 0x3e,
+[Q_KEY_CODE_F5] = 0x3f,
+[Q_KEY_CODE_F6] = 0x40,
+[Q_KEY_CODE_F7] = 0x41,
+[Q_KEY_CODE_F8] = 0x42,
+[Q_KEY_CODE_F9] = 0x43,
+[Q_KEY_CODE_F10] = 0x44,
+[Q_KEY_CODE_NUM_LOCK] = 0x45,
+[Q_KEY_CODE_SCROLL_LOCK] = 0x46,
+
+[Q_KEY_CODE_KP_DIVIDE] = 0xb5,
+[Q_KEY_CODE_KP_MULTIPLY] = 0x37,
+[Q_KEY_CODE_KP_SUBTRACT] = 0x4a,
+[Q_KEY_CODE_KP_ADD] = 0x4e,
+[Q_KEY_CODE_KP_ENTER] = 0x9c,
+[Q_KEY_CODE_KP_DECIMAL] = 0x53,
+[Q_KEY_CODE_SYSRQ] = 0x54,
+
+[Q_KEY_CODE_KP_0] = 0x52,
+[Q_KEY_CODE_KP_1] = 0x4f,
+[Q_KEY_CODE_KP_2] = 0x50,
+[Q_KEY_CODE_KP_3] = 0x51,
+[Q_KEY_CODE_KP_4] = 0x4b,
+[Q_KEY_CODE_KP_5] = 0x4c,
+[Q_KEY_CODE_KP_6] = 0x4d,
+[Q_KEY_CODE_KP_7] = 0x47,
+[Q_KEY_CODE_KP_8] = 0x48,
+[Q_KEY_CODE_KP_9] = 0x49,
+
+[Q_KEY_CODE_LESS] = 0x56,
+
+[Q_KEY_CODE_F11] = 0x57,
+[Q_KEY_CODE_F12] = 0x58,
+
+[Q_KEY_CODE_PRINT] = 0xb7,
+
+[Q_KEY_CODE_HOME] = 0xc7,
+[Q_KEY_CODE_PGUP] = 0xc9,
+[Q_KEY_CODE_PGDN] = 0xd1,
+[Q_KEY_CODE_END] = 0xcf,
+
+[Q_KEY_CODE_LEFT] = 0xcb,
+[Q_KEY_CODE_UP] = 0xc8,
+[Q_KEY_CODE_DOWN] = 0xd0,
+[Q_KEY_CODE_RIGHT] = 0xcd,
+
+[Q_KEY_CODE_INSERT] = 0xd2,
+[Q_KEY_CODE_DELETE] = 0xd3,
+#ifdef NEED_CPU_H
+#if defined(TARGET_SPARC) !defined(TARGET_SPARC64)
+[Q_KEY_CODE_STOP] = 0xf0,
+
[Qemu-devel] [PATCH v7 0/6] convert sendkey to qapi
This series converted 'sendkey' command to qapi. The raw value in hexadecimal format is not supported by 'send-key' of qmp. Amos Kong (6): fix doc of using raw values with sendkey monitor: rename keyname '' to 'less' hmp: rename arguments qapi: generate list struct and visit_list for enum add the QKeyCode enum and the key_defs table qapi: convert sendkey console.h |5 + hmp-commands.hx | 10 +- hmp.c | 55 +++ hmp.h |1 + input.c | 251 + monitor.c | 245 +--- qapi-schema.json | 46 + qmp-commands.hx | 28 ++ scripts/qapi-types.py | 16 +++- scripts/qapi-visit.py | 14 +++- 10 files changed, 421 insertions(+), 250 deletions(-) --- Changes from v1: - using a JSON array for the key names - rename new error to 'QERR_OVERFLOW' - fix command descriptions - qapi: generate list struct for enum - add '' fixing Changes from v2: - fix support of raw value in hexadecimal format - fix bug in processing of '-x' - don't generate useless cleanup functions for enum - introduced two functions for enum in qapi scripts - fix command description - drop keys number limitation in sendkey - drop patch: qerror: add QERR_OVERFLOW Changes from v3: - move key_defs[] to console.h - link mapping tables by enum values - rename 'sendkey' to 'send-key' for qmp Changes from v4: - rename 'KeyCodes' to 'QKeyCode' - fix default hold-time - move qmp_send_key(), key_defs to input.c - duplicate the keylist in qmp_send_key() - drop struct KeyDef - handle invalid key/index in hmp_send_key() Changes from v5: - split the addition of the QKeyCode enum and the key_defs table - split help functions definition - fix cmd completion and make key_defs static - drop ps2 trival fix, will post it by another thread Changes from v6: - split convert patch to two patches, and do the refactorings in first patch.
Re: [Qemu-devel] [PATCH 0/5 v2] cpu: make a child of DeviceState
Am 20.08.2012 01:39, schrieb Igor Mammedov: this is th 3rd approach to make CPU a child of DeviceState for both kinds of targets *-user and *-softmmu. It seems with current state of qemu it doesn't take too much effort to make it compile. Please check if it doesn't break something on other targets/archs/hosts than i386. what's tested: - compile tested building all targets on FC17x64 host. - briefly tested i386 user and softmmu targets Anthony Liguori (1): qdev: split up header so it can be used in cpu.h Igor Mammedov (4): move qemu_irq typedef out of cpu-common.h qapi-types.h doesn't really need to include qemu-common.h cleanup error.h, included qapi-types.h aready has stdbool.h make CPU a child of DeviceState error.h |1 - hw/arm-misc.h |1 + hw/bt.h |2 + hw/devices.h |2 + hw/irq.h |2 + hw/mc146818rtc.c |1 + hw/omap.h |1 + hw/qdev-addr.c|1 + hw/qdev-core.h| 240 hw/qdev-monitor.h | 16 ++ hw/qdev-properties.c |1 + hw/qdev-properties.h | 128 + hw/qdev.c |1 + hw/qdev.h | 371 + hw/soc_dma.h |1 + hw/xen.h |1 + include/qemu/cpu.h|6 +- qemu-common.h |1 - scripts/qapi-types.py |2 +- sysemu.h |1 + 20 files changed, 407 insertions(+), 373 deletions(-) create mode 100644 hw/qdev-core.h create mode 100644 hw/qdev-monitor.h create mode 100644 hw/qdev-properties.h I'd prefer if you could keep the following simple pattern: * Start includes in *.c files with config.h (optionally) and qemu-common.h. * Don't include standard include files which are already included in qemu-common.h * Don't include qemu-common.h in *.h files. Regards, Stefan Weil
[Qemu-devel] [PATCH v7 1/6] fix doc of using raw values with sendkey
(qemu) sendkey a
(qemu) sendkey 0x1e
(qemu) sendkey #0x1e
unknown key: '#0x1e'
The last command doesn't work, '#' is not requested before
raw values, and the raw value in decimal format is not supported.
Signed-off-by: Amos Kong ak...@redhat.com
---
hmp-commands.hx |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/hmp-commands.hx b/hmp-commands.hx
index f6104b0..6a70a9c 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -512,9 +512,9 @@ STEXI
@item sendkey @var{keys}
@findex sendkey
-Send @var{keys} to the emulator. @var{keys} could be the name of the
-key or @code{#} followed by the raw value in either decimal or hexadecimal
-format. Use @code{-} to press several keys simultaneously. Example:
+Send @var{keys} to the guest. @var{keys} could be the name of the
+key or the raw value in hexadecimal format. Use @code{-} to press
+several keys simultaneously. Example:
@example
sendkey ctrl-alt-f1
@end example
--
1.7.1
[Qemu-devel] [PATCH v7 2/6] monitor: rename keyname '' to 'less'
There are many maps of keycode 0x56 in pc-bios/keymaps/*
pc-bios/keymaps/common:less 0x56
pc-bios/keymaps/common:greater 0x56 shift
pc-bios/keymaps/common:bar 0x56 altgr
pc-bios/keymaps/common:brokenbar 0x56 shift altgr
This patch just renamed '' to 'less', QAPI might add new
variable by adding a prefix to keyname, '$PREFIX_' is not
available, '$PREFIX_less' is ok.
For compatibility, convert user inputted '' to 'less'.
Signed-off-by: Amos Kong ak...@redhat.com
---
monitor.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/monitor.c b/monitor.c
index ce42466..1082a93 100644
--- a/monitor.c
+++ b/monitor.c
@@ -1400,7 +1400,7 @@ static const KeyDef key_defs[] = {
{ 0x48, kp_8 },
{ 0x49, kp_9 },
-{ 0x56, },
+{ 0x56, less },
{ 0x57, f11 },
{ 0x58, f12 },
@@ -1504,6 +1504,13 @@ static void do_sendkey(Monitor *mon, const QDict *qdict)
monitor_printf(mon, too many keys\n);
return;
}
+
+/* Be compatible with old interface, convert user inputted */
+if (!strncmp(keyname_buf, , 1) keyname_len == 1) {
+pstrcpy(keyname_buf, sizeof(keyname_buf), less);
+keyname_len = 4;
+}
+
keyname_buf[keyname_len] = 0;
keycode = get_keycode(keyname_buf);
if (keycode 0) {
--
1.7.1
[Qemu-devel] [PATCH v7 4/6] qapi: generate list struct and visit_list for enum
Currently, if we define an 'enum' and use it in one command's
data, list struct for enum could not be generated, but it's
used in qmp function.
For example: KeyCodesList could not be generated.
qapi-schema.json:
{ 'enum': 'KeyCodes',
'data': [ 'shift', 'alt' ... ] }
{ 'command': 'sendkey',
'data': { 'keys': ['KeyCodes'], '*hold-time': 'int' } }
qmp-command.h:
void qmp_sendkey(KeyCodesList * keys, bool has_hold_time, int64_t
hold_time, Error **errp);
This patch lets qapi generate list struct and visit_list for enum.
Signed-off-by: Amos Kong ak...@redhat.com
---
scripts/qapi-types.py | 16 +++-
scripts/qapi-visit.py | 14 +-
2 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/scripts/qapi-types.py b/scripts/qapi-types.py
index cf601ae..49ef569 100644
--- a/scripts/qapi-types.py
+++ b/scripts/qapi-types.py
@@ -28,6 +28,16 @@ typedef struct %(name)sList
''',
name=name)
+def generate_fwd_enum_struct(name, members):
+return mcgen('''
+typedef struct %(name)sList
+{
+%(name)s value;
+struct %(name)sList *next;
+} %(name)sList;
+''',
+ name=name)
+
def generate_struct(structname, fieldname, members):
ret = mcgen('''
struct %(name)s
@@ -276,7 +286,8 @@ for expr in exprs:
if expr.has_key('type'):
ret += generate_fwd_struct(expr['type'], expr['data'])
elif expr.has_key('enum'):
-ret += generate_enum(expr['enum'], expr['data'])
+ret += generate_enum(expr['enum'], expr['data']) + \n
+ret += generate_fwd_enum_struct(expr['enum'], expr['data'])
fdef.write(generate_enum_lookup(expr['enum'], expr['data']))
elif expr.has_key('union'):
ret += generate_fwd_struct(expr['union'], expr['data']) + \n
@@ -300,6 +311,9 @@ for expr in exprs:
fdef.write(generate_type_cleanup(expr['union'] + List) + \n)
ret += generate_type_cleanup_decl(expr['union'])
fdef.write(generate_type_cleanup(expr['union']) + \n)
+elif expr.has_key('enum'):
+ret += generate_type_cleanup_decl(expr['enum'] + List)
+fdef.write(generate_type_cleanup(expr['enum'] + List) + \n)
else:
continue
fdecl.write(ret)
diff --git a/scripts/qapi-visit.py b/scripts/qapi-visit.py
index 04ef7c4..cbec24d 100644
--- a/scripts/qapi-visit.py
+++ b/scripts/qapi-visit.py
@@ -217,6 +217,16 @@ void visit_type_%(name)sList(Visitor *m, %(name)sList **
obj, const char *name,
return ret
+def generate_enum_declaration(name, members, genlist=True):
+ret =
+if genlist:
+ret += mcgen('''
+void visit_type_%(name)sList(Visitor *m, %(name)sList ** obj, const char
*name, Error **errp);
+''',
+ name=name)
+
+return ret
+
def generate_decl_enum(name, members, genlist=True):
return mcgen('''
@@ -335,10 +345,12 @@ for expr in exprs:
ret += generate_declaration(expr['union'], expr['data'])
fdecl.write(ret)
elif expr.has_key('enum'):
-ret = generate_visit_enum(expr['enum'], expr['data'])
+ret = generate_visit_list(expr['enum'], expr['data'])
+ret += generate_visit_enum(expr['enum'], expr['data'])
fdef.write(ret)
ret = generate_decl_enum(expr['enum'], expr['data'])
+ret += generate_enum_declaration(expr['enum'], expr['data'])
fdecl.write(ret)
fdecl.write('''
--
1.7.1
[Qemu-devel] [PATCH v7 6/6] qapi: convert sendkey
Convert 'sendkey' to use QAPI.
QAPI passes key's index of mapping table to qmp_send_key(),
not keycode. So we use help functions to convert key/code to
index of key_defs, and 'index' will be converted to 'keycode'
inside qmp_send_key().
For qmp, QAPI would check invalid key and raise error.
For hmp, invalid key is checked in hmp_send_key().
'send-key' of QMP doesn't support key in hexadecimal format.
Signed-off-by: Amos Kong ak...@redhat.com
---
console.h|1 -
hmp-commands.hx |2 +-
hmp.c| 55 ++
hmp.h|1 +
input.c | 67 +-
monitor.c| 87 --
qapi-schema.json | 20
qmp-commands.hx | 28 +
8 files changed, 171 insertions(+), 90 deletions(-)
diff --git a/console.h b/console.h
index 7934b11..c702b23 100644
--- a/console.h
+++ b/console.h
@@ -399,7 +399,6 @@ static inline int vnc_display_pw_expire(DisplayState *ds,
time_t expires)
void curses_display_init(DisplayState *ds, int full_screen);
/* input.c */
-extern const int key_defs[];
int index_from_key(const char *key);
int index_from_keycode(int code);
diff --git a/hmp-commands.hx b/hmp-commands.hx
index bd0c6c9..5cee131 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -505,7 +505,7 @@ ETEXI
.args_type = keys:s,hold-time:i?,
.params = keys [hold_ms],
.help = send keys to the VM (e.g. 'sendkey ctrl-alt-f1',
default hold time=100 ms),
-.mhandler.cmd = do_sendkey,
+.mhandler.cmd = hmp_send_key,
},
STEXI
diff --git a/hmp.c b/hmp.c
index a9d5675..ca021bb 100644
--- a/hmp.c
+++ b/hmp.c
@@ -19,6 +19,7 @@
#include qemu-timer.h
#include qmp-commands.h
#include monitor.h
+#include console.h
static void hmp_handle_error(Monitor *mon, Error **errp)
{
@@ -1102,3 +1103,57 @@ void hmp_closefd(Monitor *mon, const QDict *qdict)
qmp_closefd(fdname, errp);
hmp_handle_error(mon, errp);
}
+
+void hmp_send_key(Monitor *mon, const QDict *qdict)
+{
+const char *keys = qdict_get_str(qdict, keys);
+QKeyCodeList *keylist, *head = NULL, *tmp = NULL;
+int has_hold_time = qdict_haskey(qdict, hold-time);
+int hold_time = qdict_get_try_int(qdict, hold-time, -1);
+Error *err = NULL;
+char keyname_buf[16];
+char *separator;
+int keyname_len, idx;
+
+while (1) {
+separator = strchr(keys, '-');
+keyname_len = separator ? separator - keys : strlen(keys);
+pstrcpy(keyname_buf, sizeof(keyname_buf), keys);
+
+/* Be compatible with old interface, convert user inputted */
+if (!strncmp(keyname_buf, , 1) keyname_len == 1) {
+pstrcpy(keyname_buf, sizeof(keyname_buf), less);
+keyname_len = 4;
+}
+keyname_buf[keyname_len] = 0;
+
+idx = index_from_key(keyname_buf);
+if (idx == Q_KEY_CODE_MAX) {
+monitor_printf(mon, invalid parameter: %s\n, keyname_buf);
+break;
+}
+
+keylist = g_malloc0(sizeof(*keylist));
+keylist-value = idx;
+keylist-next = NULL;
+
+if (!head) {
+head = keylist;
+}
+if (tmp) {
+tmp-next = keylist;
+}
+tmp = keylist;
+
+if (!separator) {
+break;
+}
+keys = separator + 1;
+}
+
+if (idx != Q_KEY_CODE_MAX) {
+qmp_send_key(head, has_hold_time, hold_time, err);
+}
+hmp_handle_error(mon, err);
+qapi_free_QKeyCodeList(head);
+}
diff --git a/hmp.h b/hmp.h
index 7dd93bf..8e7838c 100644
--- a/hmp.h
+++ b/hmp.h
@@ -71,5 +71,6 @@ void hmp_netdev_add(Monitor *mon, const QDict *qdict);
void hmp_netdev_del(Monitor *mon, const QDict *qdict);
void hmp_getfd(Monitor *mon, const QDict *qdict);
void hmp_closefd(Monitor *mon, const QDict *qdict);
+void hmp_send_key(Monitor *mon, const QDict *qdict);
#endif
diff --git a/input.c b/input.c
index 5630cb1..c4b0619 100644
--- a/input.c
+++ b/input.c
@@ -28,6 +28,7 @@
#include console.h
#include error.h
#include qmp-commands.h
+#include qapi-types.h
static QEMUPutKBDEvent *qemu_put_kbd_event;
static void *qemu_put_kbd_event_opaque;
@@ -37,7 +38,7 @@ static QTAILQ_HEAD(, QEMUPutMouseEntry) mouse_handlers =
static NotifierList mouse_mode_notifiers =
NOTIFIER_LIST_INITIALIZER(mouse_mode_notifiers);
-const int key_defs[] = {
+static const int key_defs[] = {
[Q_KEY_CODE_SHIFT] = 0x2a,
[Q_KEY_CODE_SHIFT_R] = 0x36,
@@ -223,6 +224,70 @@ int index_from_keycode(int code)
return i;
}
+static QKeyCodeList *keycodes;
+static QEMUTimer *key_timer;
+
+static void release_keys(void *opaque)
+{
+int keycode;
+QKeyCodeList *p;
+
+for (p = keycodes; p != NULL; p = p-next) {
+keycode = key_defs[p-value];
+if (keycode 0x80) {
+kbd_put_keycode(0xe0);
+}
+
[Qemu-devel] [PATCH v7 3/6] hmp: rename arguments
Rename 'string' to 'keys', rename 'hold_time' to 'hold-time'.
Signed-off-by: Amos Kong ak...@redhat.com
---
hmp-commands.hx |2 +-
monitor.c | 14 +++---
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/hmp-commands.hx b/hmp-commands.hx
index 6a70a9c..bd0c6c9 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -502,7 +502,7 @@ ETEXI
{
.name = sendkey,
-.args_type = string:s,hold_time:i?,
+.args_type = keys:s,hold-time:i?,
.params = keys [hold_ms],
.help = send keys to the VM (e.g. 'sendkey ctrl-alt-f1',
default hold time=100 ms),
.mhandler.cmd = do_sendkey,
diff --git a/monitor.c b/monitor.c
index 1082a93..e9665d1 100644
--- a/monitor.c
+++ b/monitor.c
@@ -1480,9 +1480,9 @@ static void do_sendkey(Monitor *mon, const QDict *qdict)
char keyname_buf[16];
char *separator;
int keyname_len, keycode, i;
-const char *string = qdict_get_str(qdict, string);
-int has_hold_time = qdict_haskey(qdict, hold_time);
-int hold_time = qdict_get_try_int(qdict, hold_time, -1);
+const char *keys = qdict_get_str(qdict, keys);
+int has_hold_time = qdict_haskey(qdict, hold-time);
+int hold_time = qdict_get_try_int(qdict, hold-time, -1);
if (nb_pending_keycodes 0) {
qemu_del_timer(key_timer);
@@ -1492,10 +1492,10 @@ static void do_sendkey(Monitor *mon, const QDict *qdict)
hold_time = 100;
i = 0;
while (1) {
-separator = strchr(string, '-');
-keyname_len = separator ? separator - string : strlen(string);
+separator = strchr(keys, '-');
+keyname_len = separator ? separator - keys : strlen(keys);
if (keyname_len 0) {
-pstrcpy(keyname_buf, sizeof(keyname_buf), string);
+pstrcpy(keyname_buf, sizeof(keyname_buf), keys);
if (keyname_len sizeof(keyname_buf) - 1) {
monitor_printf(mon, invalid key: '%s...'\n, keyname_buf);
return;
@@ -1521,7 +1521,7 @@ static void do_sendkey(Monitor *mon, const QDict *qdict)
}
if (!separator)
break;
-string = separator + 1;
+keys = separator + 1;
}
nb_pending_keycodes = i;
/* key down events */
--
1.7.1
