Re: [Qemu-devel] [PATCH] posix-aio-compat: Fix idle_threads counter

2011-05-04 Thread Stefan Hajnoczi
On Tue, May 3, 2011 at 5:53 PM, Kevin Wolf  wrote:
> Am 03.05.2011 17:56, schrieb Stefan Hajnoczi:
>> On Tue, May 3, 2011 at 2:26 PM, Kevin Wolf  wrote:
>>> A thread should only be counted as idle when it really is waiting for new
>>> requests. Without this patch, sometimes too few threads are started as busy
>>> threads are counted as idle.
>>>
>>> Not sure if it makes a difference in practice outside some artificial
>>> qemu-io/qemu-img tests, but I think the change makes sense in any case.
>>>
>>> Signed-off-by: Kevin Wolf 
>>> ---
>>>  posix-aio-compat.c |    6 ++
>>>  1 files changed, 2 insertions(+), 4 deletions(-)
>>
>> I think the critical change here is that idle_threads is not being
>> incremented by spawn_thread().  This means that we will keep spawning
>> threads as new requests come in and until the first thread goes idle.
>>
>> Previously you could imagine a scenario where we spawn a thread but
>> don't schedule it yet.  Then we immediately submit more I/O and since
>> idle_threads was incremented we don't spawn additional threads to
>> handle the requests.
>>
>> Are these the cases you were thinking about?
>
> Yes, this is the case that I noticed.
>
> However, I'm not sure if this is really the critical change. In this
> case, it would take a bit longer until you get your full 64 threads, but
> you should get there eventually and then it shouldn't impact performance
> any more.
>
> However, what I saw in my test case (qemu-img always running 16
> sequential read requests in parallel) was that I only got 16 threads.
> This sounds logical, but in fact you seem to need always one thread more
> for good performance (I don't fully understand this yet). And with this
> patch, you actually get 17 threads. The difference was like 8s vs. 22s
> for the same requests, and using more than 17 threads doesn't further
> improve it.

Wow, 8s vs 22s is a big difference.  Did you run any guest benchmarks?

Stefan



Re: [Qemu-devel] [PATCH] ide: cleanup warnings

2011-05-04 Thread Kevin Wolf
Am 03.05.2011 22:03, schrieb Andrea Arcangeli:
> Hello,
> 
> This is just a minor cleanup adding \n.

Thanks, applied to the block branch.

> On a side note, it was good idea to keep it under DEBUG_IDE because if
> iscsi server reboots or goes down, this would generate a flood of
> errors if it's enabled (a flood of these warnings would have been
> shown with DEBUG_IDE on in such a condition).

Isn't it a bug that qemu_aio_flush() doesn't clear aiocb/status? Should
we move the ide_set_inactive() call from ide_dma_error to ide_dma_cb?

> So I've also been wondering if it's safe to ignore these warnings when
> the iscsi server is down. The error is delivered up to ide which
> simulates a I/O error for the guest (something like
> BM_STATUS_PIO_RETRY), so then it should be up to the guest OS to retry
> long enough and deal with it without corrupting the guest filesystem
> image. Often local filesystems in the guest (ext4/brfs/xfs etc...)
> won't be heavily tested for I/O errors. So it would be somewhat safer
> to retry on the qemu side without passing errors up to the guest, OTOH
> the guest ide driver might eventually notice a DMA timeout if the I/O
> doesn't complete in a timely fashion, so retrying indefinitely in qemu
> aio layer wouldn't be a definitive solution to avoid triggering guest
> os bugs... So in the end this is probably the best way we can handle
> the iscsi server disconnect with ide.

This is actually something controlled by werror. With werror=stop, the
VM is stopped and the guest never sees the error, but qemu retries. With
werror=report, the error is reported to the guest which can retry.

Kevin



Re: [Qemu-devel] [PATCH v3 5/5] hpet 'driftfix': add code in hpet_timer() to compensate delayed callbacks and coalesced interrupts

2011-05-04 Thread Ulrich Obergfell

Hi Marcelo,
 
> Whats prev_period for, since in practice the period will not change
> between interrupts (OS programs comparator once, or perhaps twice
> during bootup) ?

'prev_period' is needed if a guest o/s changes the comparator period
'on the fly' (without stopping and restarting the timer).


 guest o/s changes period
   |
  ti(n-1)  |ti(n)  ti(n+1)
|  v  |  |
+-+--+

 <--- prev_period ---> <-- period -->


The idea is that each timer interrupt represents a certain quantum
of time (the comparator period). If a guest o/s changes the period
between timer interrupt 'n-1' and timer interrupt 'n', I think the
new value should not take effect before timer interrupt 'n'. Timer
interrupt 'n' still represents the old/previous quantum, and timer
interrupt 'n+1' represents the new quantum.

Hence, the patch decrements 'ticks_not_accounted' by 'prev_period'
and sets 'prev_period' to 'period' when an interrupt was delivered
to the guest o/s.

+irq_delivered = update_irq(t, 1);
+if (irq_delivered) {
+t->ticks_not_accounted -= t->prev_period;
+t->prev_period = t->period;
+} else {

Most of the time 'prev_period' is equal to 'period'. It should only
be different in the scenario shown above.


Regards,

Uli



[Qemu-devel] [PATCH] s390x: Fix debugging for unknown sigp order codes

2011-05-04 Thread Christian Borntraeger
On unknown sigp order codes we print a debug message. This patch
fixes the output, since we want to see the order_code and not
the register numbers.
Patch applies on agraf tree.

Signed-off-by: Christian Borntraeger 
 
---
 target-s390x/kvm.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: b/target-s390x/kvm.c
===
--- a/target-s390x/kvm.c
+++ b/target-s390x/kvm.c
@@ -377,7 +377,7 @@ static int handle_sigp(CPUState *env, st
 r = s390_cpu_initial_reset(target_env);
 break;
 default:
-fprintf(stderr, "KVM: unknown SIGP: 0x%x\n", ipa1);
+fprintf(stderr, "KVM: unknown SIGP: 0x%x\n", order_code);
 break;
 }
 



Re: [Qemu-devel] [PATCH 05/17] kvm: add kvm stub for arch specific stuff

2011-05-04 Thread Jan Kiszka
On 2011-05-04 07:19, Alexander Graf wrote:
> 
> On 03.05.2011, at 16:57, Jan Kiszka wrote:
> 
>> On 2011-05-03 16:17, Alexander Graf wrote:
>>>
>>> On 18.04.2011, at 20:34, Aurelien Jarno wrote:
>>>
 On Fri, Apr 15, 2011 at 05:32:46PM +0200, Alexander Graf wrote:
> We have a generic stub architecture for kvm calls, but some architectures
> are different from others. So we do want to be able to have stubs for
> architecture specific functionality as well.
>
> This patch adds kvm stubs for all architectures.
>
> Signed-off-by: Alexander Graf 
> ---
> Makefile.target   |2 +-
> target-alpha/kvm-arch-stub.c  |   26 +
> target-arm/kvm-arch-stub.c|   26 +
> target-cris/kvm-arch-stub.c   |   26 +
> target-i386/kvm-arch-stub.c   |   26 +
> target-lm32/kvm-arch-stub.c   |   26 +
> target-m68k/kvm-arch-stub.c   |   26 +
> target-microblaze/kvm-arch-stub.c |   26 +
> target-mips/kvm-arch-stub.c   |   26 +
> target-ppc/kvm-arch-stub.c|   26 +
> target-s390x/kvm-arch-stub.c  |   38 
> +
> target-sh4/kvm-arch-stub.c|   26 +
> target-sparc/kvm-arch-stub.c  |   26 +
> target-unicore32/kvm-arch-stub.c  |   26 +
> 14 files changed, 351 insertions(+), 1 deletions(-)
> create mode 100644 target-alpha/kvm-arch-stub.c
> create mode 100644 target-arm/kvm-arch-stub.c
> create mode 100644 target-cris/kvm-arch-stub.c
> create mode 100644 target-i386/kvm-arch-stub.c
> create mode 100644 target-lm32/kvm-arch-stub.c
> create mode 100644 target-m68k/kvm-arch-stub.c
> create mode 100644 target-microblaze/kvm-arch-stub.c
> create mode 100644 target-mips/kvm-arch-stub.c
> create mode 100644 target-ppc/kvm-arch-stub.c
> create mode 100644 target-s390x/kvm-arch-stub.c
> create mode 100644 target-sh4/kvm-arch-stub.c
> create mode 100644 target-sparc/kvm-arch-stub.c
> create mode 100644 target-unicore32/kvm-arch-stub.c

 Do we really want to create so much files on architectures we will never
 see KVM support? Actually I know very few things about KVM, so it would
 be better to have this patch reviewed by someone else. Avi or Anthony
 maybe?
>>>
>>> Well, the main idea is to be able to have a unified place to put stub 
>>> functions into. And as it stands with most generalizations, we either make 
>>> it generic or not :).
>>> Maybe there's some Makefile magic to only compile the stub if the file 
>>> exists? I certainly don't know of any.
>>
>> This approach looks wrong.
>>
>> The point of kvm stubs is to allow generic components to be built
>> independently of kvm enabled/disabled. But target-specific callbacks
>> can't be part of generic components anyway. So there is no need for a
>> stub, those bits will be built per-target anyway.
>>
>> The examples you provided with this patch underline it:
>> s390-virtio-bus.c should be built for s390 but nothing else.
> 
> And it is, yes. The point is to not require #ifdefs in device emulation code 
> :).

But that's not the purpose of the stubs. They shall avoid building
components target specific when just the kvm on/off dependency would
force them to. Moreover, I do not see any need for such in
infrastructure beyond s390 when considering that case valid.

Why not simply define those few functions as static inline in the
already s390-specific header depending on #ifdef CONFIG_KVM?

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux



Re: [Qemu-devel] [PATCH] s390x: Fix debugging for unknown sigp order codes

2011-05-04 Thread Alexander Graf

On 04.05.2011, at 10:30, Christian Borntraeger wrote:

> On unknown sigp order codes we print a debug message. This patch
> fixes the output, since we want to see the order_code and not
> the register numbers.
> Patch applies on agraf tree.
> 
> Signed-off-by: Christian Borntraeger 

Thanks, applied to my local tree.


Alex




[Qemu-devel] IPv6 support for TCP migrations

2011-05-04 Thread nick
Hi,

Currently migration-tcp.c uses the IPv4-only socket functions, making
migrations over IPv6 impossible. Following is a tentative patch that switches
it to use inet_connect() and inet_listen(). 

However, the patch loses the non-blocking connect() behaviour seen with the
previous code. I'm not sure how much of an issue this is - if connect() blocks
here, does it block execution of the VM? 

If so, I guess we need a non-blocking form of inet_connect(), or some way of
replicating the behaviour - it would potentially be needed for my NBD
reconnection patches too? I can see that a blocking connect() might not be an
issue while the KVM process is starting up, but could cause problems if we
try to reconnect while emulation is ongoing.

Thoughts?

/Nick




[Qemu-devel] [PATCH] migration-tcp: Allow incoming and outgoing migrations over IPv6

2011-05-04 Thread nick
From: Nick Thomas 

Signed-off-by: Nick Thomas 
---
 migration-tcp.c |   85 ---
 1 files changed, 12 insertions(+), 73 deletions(-)

diff --git a/migration-tcp.c b/migration-tcp.c
index d3d80c9..8ae778e 100644
--- a/migration-tcp.c
+++ b/migration-tcp.c
@@ -48,46 +48,14 @@ static int tcp_close(FdMigrationState *s)
 return 0;
 }
 
-
-static void tcp_wait_for_connect(void *opaque)
-{
-FdMigrationState *s = opaque;
-int val, ret;
-socklen_t valsize = sizeof(val);
-
-DPRINTF("connect completed\n");
-do {
-ret = getsockopt(s->fd, SOL_SOCKET, SO_ERROR, (void *) &val, &valsize);
-} while (ret == -1 && (s->get_error(s)) == EINTR);
-
-if (ret < 0) {
-migrate_fd_error(s);
-return;
-}
-
-qemu_set_fd_handler2(s->fd, NULL, NULL, NULL, NULL);
-
-if (val == 0)
-migrate_fd_connect(s);
-else {
-DPRINTF("error connecting %d\n", val);
-migrate_fd_error(s);
-}
-}
-
 MigrationState *tcp_start_outgoing_migration(Monitor *mon,
  const char *host_port,
  int64_t bandwidth_limit,
  int detach,
-int blk,
-int inc)
+ int blk,
+ int inc)
 {
-struct sockaddr_in addr;
 FdMigrationState *s;
-int ret;
-
-if (parse_host_port(&addr, host_port) < 0)
-return NULL;
 
 s = qemu_mallocz(sizeof(*s));
 
@@ -104,32 +72,20 @@ MigrationState *tcp_start_outgoing_migration(Monitor *mon,
 s->state = MIG_STATE_ACTIVE;
 s->mon = NULL;
 s->bandwidth_limit = bandwidth_limit;
-s->fd = qemu_socket(PF_INET, SOCK_STREAM, 0);
-if (s->fd == -1) {
-qemu_free(s);
-return NULL;
-}
-
-socket_set_nonblock(s->fd);
 
 if (!detach) {
 migrate_fd_monitor_suspend(s, mon);
 }
 
-do {
-ret = connect(s->fd, (struct sockaddr *)&addr, sizeof(addr));
-if (ret == -1)
-ret = -(s->get_error(s));
-
-if (ret == -EINPROGRESS || ret == -EWOULDBLOCK)
-qemu_set_fd_handler2(s->fd, NULL, NULL, tcp_wait_for_connect, s);
-} while (ret == -EINTR);
+s->fd = inet_connect(host_port, SOCK_STREAM);
 
-if (ret < 0 && ret != -EINPROGRESS && ret != -EWOULDBLOCK) {
+if (s->fd == -1) {
 DPRINTF("connect failed\n");
 migrate_fd_error(s);
-} else if (ret >= 0)
+} else {
+socket_set_nonblock(s->fd);
 migrate_fd_connect(s);
+}
 
 return &s->mig_state;
 }
@@ -170,34 +126,17 @@ out2:
 
 int tcp_start_incoming_migration(const char *host_port)
 {
-struct sockaddr_in addr;
-int val;
 int s;
+char *ostr = NULL;
 
-if (parse_host_port(&addr, host_port) < 0) {
-fprintf(stderr, "invalid host/port combination: %s\n", host_port);
-return -EINVAL;
-}
-
-s = qemu_socket(PF_INET, SOCK_STREAM, 0);
-if (s == -1)
+s = inet_listen(host_port, ostr, 0, SOCK_STREAM, 0);
+if (s == -1) {
 return -socket_error();
-
-val = 1;
-setsockopt(s, SOL_SOCKET, SO_REUSEADDR, (const char *)&val, sizeof(val));
-
-if (bind(s, (struct sockaddr *)&addr, sizeof(addr)) == -1)
-goto err;
-
-if (listen(s, 1) == -1)
-goto err;
+}
 
 qemu_set_fd_handler2(s, NULL, tcp_accept_incoming_migration, NULL,
  (void *)(intptr_t)s);
 
 return 0;
-
-err:
-close(s);
-return -socket_error();
 }
+
-- 
1.7.0.4




Re: [Qemu-devel] [PATCH 05/17] kvm: add kvm stub for arch specific stuff

2011-05-04 Thread Alexander Graf

On 04.05.2011, at 10:31, Jan Kiszka wrote:

> On 2011-05-04 07:19, Alexander Graf wrote:
>> 
>> On 03.05.2011, at 16:57, Jan Kiszka wrote:
>> 
>>> On 2011-05-03 16:17, Alexander Graf wrote:
 
 On 18.04.2011, at 20:34, Aurelien Jarno wrote:
 
> On Fri, Apr 15, 2011 at 05:32:46PM +0200, Alexander Graf wrote:
>> We have a generic stub architecture for kvm calls, but some architectures
>> are different from others. So we do want to be able to have stubs for
>> architecture specific functionality as well.
>> 
>> This patch adds kvm stubs for all architectures.
>> 
>> Signed-off-by: Alexander Graf 
>> ---
>> Makefile.target   |2 +-
>> target-alpha/kvm-arch-stub.c  |   26 +
>> target-arm/kvm-arch-stub.c|   26 +
>> target-cris/kvm-arch-stub.c   |   26 +
>> target-i386/kvm-arch-stub.c   |   26 +
>> target-lm32/kvm-arch-stub.c   |   26 +
>> target-m68k/kvm-arch-stub.c   |   26 +
>> target-microblaze/kvm-arch-stub.c |   26 +
>> target-mips/kvm-arch-stub.c   |   26 +
>> target-ppc/kvm-arch-stub.c|   26 +
>> target-s390x/kvm-arch-stub.c  |   38 
>> +
>> target-sh4/kvm-arch-stub.c|   26 +
>> target-sparc/kvm-arch-stub.c  |   26 +
>> target-unicore32/kvm-arch-stub.c  |   26 +
>> 14 files changed, 351 insertions(+), 1 deletions(-)
>> create mode 100644 target-alpha/kvm-arch-stub.c
>> create mode 100644 target-arm/kvm-arch-stub.c
>> create mode 100644 target-cris/kvm-arch-stub.c
>> create mode 100644 target-i386/kvm-arch-stub.c
>> create mode 100644 target-lm32/kvm-arch-stub.c
>> create mode 100644 target-m68k/kvm-arch-stub.c
>> create mode 100644 target-microblaze/kvm-arch-stub.c
>> create mode 100644 target-mips/kvm-arch-stub.c
>> create mode 100644 target-ppc/kvm-arch-stub.c
>> create mode 100644 target-s390x/kvm-arch-stub.c
>> create mode 100644 target-sh4/kvm-arch-stub.c
>> create mode 100644 target-sparc/kvm-arch-stub.c
>> create mode 100644 target-unicore32/kvm-arch-stub.c
> 
> Do we really want to create so much files on architectures we will never
> see KVM support? Actually I know very few things about KVM, so it would
> be better to have this patch reviewed by someone else. Avi or Anthony
> maybe?
 
 Well, the main idea is to be able to have a unified place to put stub 
 functions into. And as it stands with most generalizations, we either make 
 it generic or not :).
 Maybe there's some Makefile magic to only compile the stub if the file 
 exists? I certainly don't know of any.
>>> 
>>> This approach looks wrong.
>>> 
>>> The point of kvm stubs is to allow generic components to be built
>>> independently of kvm enabled/disabled. But target-specific callbacks
>>> can't be part of generic components anyway. So there is no need for a
>>> stub, those bits will be built per-target anyway.
>>> 
>>> The examples you provided with this patch underline it:
>>> s390-virtio-bus.c should be built for s390 but nothing else.
>> 
>> And it is, yes. The point is to not require #ifdefs in device emulation code 
>> :).
> 
> But that's not the purpose of the stubs. They shall avoid building
> components target specific when just the kvm on/off dependency would
> force them to. Moreover, I do not see any need for such in
> infrastructure beyond s390 when considering that case valid.
> 
> Why not simply define those few functions as static inline in the
> already s390-specific header depending on #ifdef CONFIG_KVM?

Which already-s390-specific header depending on #ifdef CONFIG_KVM? The current 
definitions are in cpu.h which is included in code that doesn't include CONFIG*.


Alex




Re: [Qemu-devel] [PATCH 05/17] kvm: add kvm stub for arch specific stuff

2011-05-04 Thread Jan Kiszka
On 2011-05-04 10:40, Alexander Graf wrote:
> 
> On 04.05.2011, at 10:31, Jan Kiszka wrote:
> 
>> On 2011-05-04 07:19, Alexander Graf wrote:
>>>
>>> On 03.05.2011, at 16:57, Jan Kiszka wrote:
>>>
 On 2011-05-03 16:17, Alexander Graf wrote:
>
> On 18.04.2011, at 20:34, Aurelien Jarno wrote:
>
>> On Fri, Apr 15, 2011 at 05:32:46PM +0200, Alexander Graf wrote:
>>> We have a generic stub architecture for kvm calls, but some 
>>> architectures
>>> are different from others. So we do want to be able to have stubs for
>>> architecture specific functionality as well.
>>>
>>> This patch adds kvm stubs for all architectures.
>>>
>>> Signed-off-by: Alexander Graf 
>>> ---
>>> Makefile.target   |2 +-
>>> target-alpha/kvm-arch-stub.c  |   26 +
>>> target-arm/kvm-arch-stub.c|   26 +
>>> target-cris/kvm-arch-stub.c   |   26 +
>>> target-i386/kvm-arch-stub.c   |   26 +
>>> target-lm32/kvm-arch-stub.c   |   26 +
>>> target-m68k/kvm-arch-stub.c   |   26 +
>>> target-microblaze/kvm-arch-stub.c |   26 +
>>> target-mips/kvm-arch-stub.c   |   26 +
>>> target-ppc/kvm-arch-stub.c|   26 +
>>> target-s390x/kvm-arch-stub.c  |   38 
>>> +
>>> target-sh4/kvm-arch-stub.c|   26 +
>>> target-sparc/kvm-arch-stub.c  |   26 +
>>> target-unicore32/kvm-arch-stub.c  |   26 +
>>> 14 files changed, 351 insertions(+), 1 deletions(-)
>>> create mode 100644 target-alpha/kvm-arch-stub.c
>>> create mode 100644 target-arm/kvm-arch-stub.c
>>> create mode 100644 target-cris/kvm-arch-stub.c
>>> create mode 100644 target-i386/kvm-arch-stub.c
>>> create mode 100644 target-lm32/kvm-arch-stub.c
>>> create mode 100644 target-m68k/kvm-arch-stub.c
>>> create mode 100644 target-microblaze/kvm-arch-stub.c
>>> create mode 100644 target-mips/kvm-arch-stub.c
>>> create mode 100644 target-ppc/kvm-arch-stub.c
>>> create mode 100644 target-s390x/kvm-arch-stub.c
>>> create mode 100644 target-sh4/kvm-arch-stub.c
>>> create mode 100644 target-sparc/kvm-arch-stub.c
>>> create mode 100644 target-unicore32/kvm-arch-stub.c
>>
>> Do we really want to create so much files on architectures we will never
>> see KVM support? Actually I know very few things about KVM, so it would
>> be better to have this patch reviewed by someone else. Avi or Anthony
>> maybe?
>
> Well, the main idea is to be able to have a unified place to put stub 
> functions into. And as it stands with most generalizations, we either 
> make it generic or not :).
> Maybe there's some Makefile magic to only compile the stub if the file 
> exists? I certainly don't know of any.

 This approach looks wrong.

 The point of kvm stubs is to allow generic components to be built
 independently of kvm enabled/disabled. But target-specific callbacks
 can't be part of generic components anyway. So there is no need for a
 stub, those bits will be built per-target anyway.

 The examples you provided with this patch underline it:
 s390-virtio-bus.c should be built for s390 but nothing else.
>>>
>>> And it is, yes. The point is to not require #ifdefs in device emulation 
>>> code :).
>>
>> But that's not the purpose of the stubs. They shall avoid building
>> components target specific when just the kvm on/off dependency would
>> force them to. Moreover, I do not see any need for such in
>> infrastructure beyond s390 when considering that case valid.
>>
>> Why not simply define those few functions as static inline in the
>> already s390-specific header depending on #ifdef CONFIG_KVM?
> 
> Which already-s390-specific header depending on #ifdef CONFIG_KVM? The 
> current definitions are in cpu.h which is included in code that doesn't 
> include CONFIG*.

cpu.h is target-specific, thus must pull in all the configs (e.g. the
prototypes are already under CONFIG_USER_ONLY).

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux



Re: [Qemu-devel] [PATCH 05/17] kvm: add kvm stub for arch specific stuff

2011-05-04 Thread Alexander Graf

On 04.05.2011, at 10:43, Jan Kiszka wrote:

> On 2011-05-04 10:40, Alexander Graf wrote:
>> 
>> On 04.05.2011, at 10:31, Jan Kiszka wrote:
>> 
>>> On 2011-05-04 07:19, Alexander Graf wrote:
 
 On 03.05.2011, at 16:57, Jan Kiszka wrote:
 
> On 2011-05-03 16:17, Alexander Graf wrote:
>> 
>> On 18.04.2011, at 20:34, Aurelien Jarno wrote:
>> 
>>> On Fri, Apr 15, 2011 at 05:32:46PM +0200, Alexander Graf wrote:
 We have a generic stub architecture for kvm calls, but some 
 architectures
 are different from others. So we do want to be able to have stubs for
 architecture specific functionality as well.
 
 This patch adds kvm stubs for all architectures.
 
 Signed-off-by: Alexander Graf 
 ---
 Makefile.target   |2 +-
 target-alpha/kvm-arch-stub.c  |   26 +
 target-arm/kvm-arch-stub.c|   26 +
 target-cris/kvm-arch-stub.c   |   26 +
 target-i386/kvm-arch-stub.c   |   26 +
 target-lm32/kvm-arch-stub.c   |   26 +
 target-m68k/kvm-arch-stub.c   |   26 +
 target-microblaze/kvm-arch-stub.c |   26 +
 target-mips/kvm-arch-stub.c   |   26 +
 target-ppc/kvm-arch-stub.c|   26 +
 target-s390x/kvm-arch-stub.c  |   38 
 +
 target-sh4/kvm-arch-stub.c|   26 +
 target-sparc/kvm-arch-stub.c  |   26 +
 target-unicore32/kvm-arch-stub.c  |   26 +
 14 files changed, 351 insertions(+), 1 deletions(-)
 create mode 100644 target-alpha/kvm-arch-stub.c
 create mode 100644 target-arm/kvm-arch-stub.c
 create mode 100644 target-cris/kvm-arch-stub.c
 create mode 100644 target-i386/kvm-arch-stub.c
 create mode 100644 target-lm32/kvm-arch-stub.c
 create mode 100644 target-m68k/kvm-arch-stub.c
 create mode 100644 target-microblaze/kvm-arch-stub.c
 create mode 100644 target-mips/kvm-arch-stub.c
 create mode 100644 target-ppc/kvm-arch-stub.c
 create mode 100644 target-s390x/kvm-arch-stub.c
 create mode 100644 target-sh4/kvm-arch-stub.c
 create mode 100644 target-sparc/kvm-arch-stub.c
 create mode 100644 target-unicore32/kvm-arch-stub.c
>>> 
>>> Do we really want to create so much files on architectures we will never
>>> see KVM support? Actually I know very few things about KVM, so it would
>>> be better to have this patch reviewed by someone else. Avi or Anthony
>>> maybe?
>> 
>> Well, the main idea is to be able to have a unified place to put stub 
>> functions into. And as it stands with most generalizations, we either 
>> make it generic or not :).
>> Maybe there's some Makefile magic to only compile the stub if the file 
>> exists? I certainly don't know of any.
> 
> This approach looks wrong.
> 
> The point of kvm stubs is to allow generic components to be built
> independently of kvm enabled/disabled. But target-specific callbacks
> can't be part of generic components anyway. So there is no need for a
> stub, those bits will be built per-target anyway.
> 
> The examples you provided with this patch underline it:
> s390-virtio-bus.c should be built for s390 but nothing else.
 
 And it is, yes. The point is to not require #ifdefs in device emulation 
 code :).
>>> 
>>> But that's not the purpose of the stubs. They shall avoid building
>>> components target specific when just the kvm on/off dependency would
>>> force them to. Moreover, I do not see any need for such in
>>> infrastructure beyond s390 when considering that case valid.
>>> 
>>> Why not simply define those few functions as static inline in the
>>> already s390-specific header depending on #ifdef CONFIG_KVM?
>> 
>> Which already-s390-specific header depending on #ifdef CONFIG_KVM? The 
>> current definitions are in cpu.h which is included in code that doesn't 
>> include CONFIG*.
> 
> cpu.h is target-specific, thus must pull in all the configs (e.g. the
> prototypes are already under CONFIG_USER_ONLY).

Hrm - I certainly did have it #ifdef'ed in cpu.h at first. There was a reason I 
moved it over. Let me see if maybe I can get it working with #ifdefery in cpu.h 
again.


Alex




Re: [Qemu-devel] [PATCH v2] Import Linux headers for KVM and vhost

2011-05-04 Thread Jan Kiszka
On 2011-05-03 23:37, Michael S. Tsirkin wrote:
> On Tue, May 03, 2011 at 12:59:06PM -0500, Anthony Liguori wrote:
>> On 05/03/2011 12:55 PM, Jan Kiszka wrote:
>>> On 2011-05-03 19:45, Anthony Liguori wrote:
 On 05/03/2011 12:30 PM, Peter Maydell wrote:
> On 3 May 2011 17:48, Jan Kiszka   wrote:
>> Kernel headers were automatically imported from current kvm.git,
>> 93c016c8c4. Some are not covered by any license and can be considered
>> GPLv2 with user space exception.
>
> Hmm. Can't we just get whoever owns those files to apply a suitable
> copyright and license header to them? Committing files to qemu.git
> which don't have a clear (and clearly stated) copyright/license seems
> like a bad plan to me...

 Which are the headers in question?
>>>
>>> include/asm-powerpc:explicit GPLv2
>>> include/asm-s390:   explicit GPLv2
>>> include/asm/x86:no license mentioned
>>> include/linux/kvm*: no license mentioned
>>> include/linux/vhost:no license mentioned
>>
>> Michael/Avi, can ya'll add copyrights/licenses as appropriate?
> 
> All kernel is GPLv2 with userspace exceptions.

That's not that simple. There is a lot of dual licensing, and the virtio
header are BSD 3-clause as we know.

>  The explicit GPLv2
> licenses are likely uninitentional.  So I don't really believe licenses
> are applicable in headers, we see how this creates confusion.

Well, if you state that your work on headers is not copyrighted and can
thus be used under any license, that's OK. But you can't speak for
others. And we should better avoid that such discussions escalate to any
legal authorities. :)

> 
> Just place the kernel COPYING file into the include directory?

That is one option I've already built into my latest patch version, even
for the case we come to a more explicit solution.

But one point of all this is to make life easier for those poor people
who have check a qemu source package before redistribution for included
licenses. The clearer the terms are expressed, the easier these
"unproductive" processes become. You can't imagine what activities that
vague "BSD" license of the virtio headers triggered here...

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux



[Qemu-devel] [Bug 723871] Re: qemu-kvm-0.14.0 Aborts with -vga qxl

2011-05-04 Thread Boris Derzhavets
git clone git://git.freedesktop.org/git/spice/qemu
cd qemu/
git checkout -b spice.v35 origin/spice.35

Allows to build qemu-kvm-spice_0.14.0+noroms-0ubuntu4qxl3_amd64.deb
with patches

larger_default_ram_size.patch
# Detect-and-use-GCC-atomic-builtins-for-locking.patch
# 0001-qxl-spice-display-move-pipe-to-ssd.patch
# 0002-qxl-implement-get_command-in-vga-mode-without-locks.patch
# 0003-qxl-spice-remove-qemu_mutex_-un-lock_iothread-around.patch
# 0004-hw-qxl-render-drop-cursor-locks-replace-with-pipe.patch

Package seems to work OK with SPICE2 PPA

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

Title:
  qemu-kvm-0.14.0 Aborts with -vga qxl

Status in QEMU:
  Confirmed
Status in “libvirt” package in Ubuntu:
  Triaged
Status in “qemu-kvm” package in Ubuntu:
  Fix Released

Bug description:
  Host CPU is Core i7 Q820.  KVM is from 2.6.35-gentoo-r5 kernel (x86_64).
  Host has spice-0.7.2 and spice-protocol-0.7.0.
  Guest is Windows XP SP3 with qxl driver 0.6.1, virtio-serial 1.1.6 and 
vdagent 0.6.3.

  qemu-kvm is started like so:
  qemu-system-x86_64 -cpu host -enable-kvm -pidfile /home/rick/qemu/hds/wxp.pid 
-drive 
file=/home/rick/qemu/hds/wxp.raw,if=virtio,media=disk,aio=native,snapshot=on -m 
768 -name WinXP -net nic,model=virtio -net user -localtime -usb -vga qxl 
-device virtio-serial -chardev spicevmc,name=vdagent,id=vdagent -device 
virtserialport,chardev=vdagent,name=com.redhat.spice.0 -spice 
port=1234,disable-ticketing -monitor stdio
  and crashes with:
  qemu-system-x86_64: /home/rick/qemu/src/qemu-kvm-0.14.0/qemu-kvm.c:1724: 
kvm_mutex_unlock: Assertion `!cpu_single_env' failed.
  Aborted

  If I use -no-kvm, it works fine.  If I use -vga std, it works fine.
  -enable-kvm and -vga qxl crashes.



[Qemu-devel] [Bug 723871] Re: qemu-kvm-0.14.0 Aborts with -vga qxl

2011-05-04 Thread Boris Derzhavets
** Attachment added: "qemu-kvm-spice based  spice.v35"
   
https://bugs.launchpad.net/qemu/+bug/723871/+attachment/2111482/+files/qemu-kvm-spice_0.14.0%2Bnoroms-0ubuntu4qxl3_amd64.deb

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

Title:
  qemu-kvm-0.14.0 Aborts with -vga qxl

Status in QEMU:
  Confirmed
Status in “libvirt” package in Ubuntu:
  Triaged
Status in “qemu-kvm” package in Ubuntu:
  Fix Released

Bug description:
  Host CPU is Core i7 Q820.  KVM is from 2.6.35-gentoo-r5 kernel (x86_64).
  Host has spice-0.7.2 and spice-protocol-0.7.0.
  Guest is Windows XP SP3 with qxl driver 0.6.1, virtio-serial 1.1.6 and 
vdagent 0.6.3.

  qemu-kvm is started like so:
  qemu-system-x86_64 -cpu host -enable-kvm -pidfile /home/rick/qemu/hds/wxp.pid 
-drive 
file=/home/rick/qemu/hds/wxp.raw,if=virtio,media=disk,aio=native,snapshot=on -m 
768 -name WinXP -net nic,model=virtio -net user -localtime -usb -vga qxl 
-device virtio-serial -chardev spicevmc,name=vdagent,id=vdagent -device 
virtserialport,chardev=vdagent,name=com.redhat.spice.0 -spice 
port=1234,disable-ticketing -monitor stdio
  and crashes with:
  qemu-system-x86_64: /home/rick/qemu/src/qemu-kvm-0.14.0/qemu-kvm.c:1724: 
kvm_mutex_unlock: Assertion `!cpu_single_env' failed.
  Aborted

  If I use -no-kvm, it works fine.  If I use -vga std, it works fine.
  -enable-kvm and -vga qxl crashes.



Re: [Qemu-devel] [PATCH 07/18] Fix typo in comment (consistant -> consistent)

2011-05-04 Thread Alon Levy
On Thu, Apr 28, 2011 at 05:20:31PM +0200, Stefan Weil wrote:
> Signed-off-by: Stefan Weil 
> ---

ACK. I assumed since you emailed qemu-trivial that these don't actually
require any acks.

>  libcacard/vcard_emul_nss.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/libcacard/vcard_emul_nss.c b/libcacard/vcard_emul_nss.c
> index baada52..f3db657 100644
> --- a/libcacard/vcard_emul_nss.c
> +++ b/libcacard/vcard_emul_nss.c
> @@ -971,7 +971,7 @@ find_blank(const char *str)
>  
>  /*
>   *  We really want to use some existing argument parsing library here. That
> - *  would give us a consistant look */
> + *  would give us a consistent look */
>  static VCardEmulOptions options;
>  #define READER_STEP 4
>  
> -- 
> 1.7.2.5
> 
> 



Re: [Qemu-devel] IPv6 support for TCP migrations

2011-05-04 Thread Daniel P. Berrange
On Wed, May 04, 2011 at 09:39:02AM +0100, n...@bytemark.co.uk wrote:
> Hi,
> 
> Currently migration-tcp.c uses the IPv4-only socket functions, making
> migrations over IPv6 impossible. Following is a tentative patch that switches
> it to use inet_connect() and inet_listen(). 
> 
> However, the patch loses the non-blocking connect() behaviour seen with the
> previous code. I'm not sure how much of an issue this is - if connect() blocks
> here, does it block execution of the VM? 
> 
> If so, I guess we need a non-blocking form of inet_connect(), or some way of
> replicating the behaviour - it would potentially be needed for my NBD
> reconnection patches too? I can see that a blocking connect() might not be an
> issue while the KVM process is starting up, but could cause problems if we
> try to reconnect while emulation is ongoing.
> 
> Thoughts?

FWIW, Juan Quintela also posted a set of patches to add IPv6 support for
migration a few weeks back, but unfortunately they don't appear to have
been merged yet:

  http://www.mail-archive.com/qemu-devel@nongnu.org/msg58954.html

IIUC, Juan's patches don't have the blocking connect() problem you
mention.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|



Re: [Qemu-devel] [PATCH v2] Import Linux headers for KVM and vhost

2011-05-04 Thread Jan Kiszka
On 2011-05-03 22:22, Peter Maydell wrote:
> On 3 May 2011 17:48, Jan Kiszka  wrote:
>> +++ b/scripts/update-linux-headers.sh
>> @@ -0,0 +1,47 @@
>> +#!/bin/sh
> 
> No -e ?
> 
>> +rm -rf $output/include/linux/*
> 
> Given that updating the kernel headers will blow away large
> subsets of include/ like this, maybe we should use a less generic
> name than "include", so it's clear that it's just a set of
> automatically maintained and updated files, rather than
> a good place to put random QEMU header files?
> 
> kernel-headers/ seems like an obvious choice.
> 
> Is it worth having a README in the directory saying "don't
> edit these, they are copies of the kernel headers, they can
> be updated with ", or is that unnecessary?
> 

No, these suggestion all make sense. I've incorporated them.

Thanks,
Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux



[Qemu-devel] s390x kvm and smp

2011-05-04 Thread Christian Borntraeger
Alex,

I have trouble getting kvm smp support running. Turns out that qemu does a kvm
run even on secondary CPUs which dont have a sane state (initial psw == 0)
triggering some program faults. Architecturally these cpus are in the stopped
state, so we should not do KVM_RUN. (these CPUs will be started by a SIGP
restart later during the boot process)

This patch seems to help (it allows me to boot and use more than 1 cpu)

--- a/cpus.c
+++ b/cpus.c
@@ -131,6 +131,10 @@ static void do_vm_stop(int reason)
 
 static int cpu_can_run(CPUState *env)
 {
+if (env->halted) {
+return 0;
+}
+
 if (env->stop) {
 return 0;
 }

but it does not look like the right solution. What are the proper
definitions for halted and stopped?

Christian



Re: [Qemu-devel] IPv6 support for TCP migrations

2011-05-04 Thread Nicholas Thomas
On Wed, 2011-05-04 at 11:13 +0100, Daniel P. Berrange wrote:
> On Wed, May 04, 2011 at 09:39:02AM +0100, n...@bytemark.co.uk wrote:
> > Hi,
> > 
> > Currently migration-tcp.c uses the IPv4-only socket functions, making
> > migrations over IPv6 impossible. Following is a tentative patch that 
> > switches
> > it to use inet_connect() and inet_listen(). 
> > 
> > However, the patch loses the non-blocking connect() behaviour seen with the
> > previous code. I'm not sure how much of an issue this is - if connect() 
> > blocks
> > here, does it block execution of the VM? 
> > 
> > If so, I guess we need a non-blocking form of inet_connect(), or some way of
> > replicating the behaviour - it would potentially be needed for my NBD
> > reconnection patches too? I can see that a blocking connect() might not be 
> > an
> > issue while the KVM process is starting up, but could cause problems if we
> > try to reconnect while emulation is ongoing.
> > 
> > Thoughts?
> 
> FWIW, Juan Quintela also posted a set of patches to add IPv6 support for
> migration a few weeks back, but unfortunately they don't appear to have
> been merged yet:
> 
>   http://www.mail-archive.com/qemu-devel@nongnu.org/msg58954.html
> 
> IIUC, Juan's patches don't have the blocking connect() problem you
> mention.

Hi,

Those patches look closer than mine, yes, although I spotted a problem
in tcp_start_common() of that patch series (Juan CC'd):

> +static int tcp_start_common(const char *str, int *fd, bool server)
> +{
> +char hostname[512];
> +const char *service;
> +const char *name;
> +struct addrinfo hints;
> +struct addrinfo *result, *rp;
> +int s;
> +int sfd;
> +int ret = -EINVAL;
> +
> +*fd = -1;
> +service = str;
> +if (get_str_sep(hostname, sizeof(hostname), &service, ':') < 0) {
> +return -EINVAL;
> +}
> +if (server && strlen(hostname) == 0) {
> +name = NULL;
> +} else {
> +name = hostname;
> +}

I think this will fail when specifying an IPv6 *address* and port, e.g:

migrate -d [::1]:5000

We already have code that does this correctly in qemu-sockets.c - 
inet_parse() - which is primarily what I was trying to get the
benefit of, in my patch. 

> +
> +/* Obtain address(es) matching host/port */
> +
> +memset(&hints, 0, sizeof(struct addrinfo));
> +hints.ai_family = AF_UNSPEC; /* Allow IPv4 or IPv6 */
> +hints.ai_socktype = SOCK_STREAM; /* Datagram socket */
> +
> +if (server) {
> +hints.ai_flags = AI_PASSIVE;
> +}
> +
> +s = getaddrinfo(name, service, &hints, &result);
> +if (s != 0) {
> +fprintf(stderr, "qemu: getaddrinfo: %s\n", gai_strerror(s));
> +return -EINVAL;
> +}
> +
> +/* getaddrinfo() returns a list of address structures.
> +   Try each address until we successfully bind/connect).
> +   If socket(2) (or bind/connect(2)) fails, we (close the socket
> +   and) try the next address. */
> +
> +for (rp = result; rp != NULL; rp = rp->ai_next) {
> +sfd = qemu_socket(rp->ai_family, rp->ai_socktype, rp->ai_protocol);
> +if (sfd == -1) {
> +ret = -errno;
> +continue;
> +}
> +socket_set_nonblock(sfd);
> +if (server) {
> +ret = tcp_server_bind(sfd, rp);
> +} else {
> +ret = tcp_client_connect(sfd, rp);
> +}
> +if (ret >= 0 || ret == -EINPROGRESS || ret == -EWOULDBLOCK) {
> +*fd = sfd;
> +break;  /* Success */
> +}
> +close(sfd);
> +}
> +
> +freeaddrinfo(result);
> +return ret;
> +}







Re: [Qemu-devel] s390x kvm and smp

2011-05-04 Thread Jan Kiszka
On 2011-05-04 12:43, Christian Borntraeger wrote:
> Alex,
> 
> I have trouble getting kvm smp support running. Turns out that qemu does a kvm
> run even on secondary CPUs which dont have a sane state (initial psw == 0)
> triggering some program faults. Architecturally these cpus are in the stopped
> state, so we should not do KVM_RUN. (these CPUs will be started by a SIGP
> restart later during the boot process)
> 
> This patch seems to help (it allows me to boot and use more than 1 cpu)
> 
> --- a/cpus.c
> +++ b/cpus.c
> @@ -131,6 +131,10 @@ static void do_vm_stop(int reason)
>  
>  static int cpu_can_run(CPUState *env)
>  {
> +if (env->halted) {
> +return 0;
> +}
> +
>  if (env->stop) {
>  return 0;
>  }
> 
> but it does not look like the right solution. What are the proper
> definitions for halted and stopped?

s390 just need to return a meaningful value from
kvm_arch_process_async_events, e.g. env->halted, see other archs.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux



Re: [Qemu-devel] ­ How to cross compile QEMU

2011-05-04 Thread 李柏舉
Hi, all

   I using cross-compiler: arm-2008q3  , no error occur .

Regards,
Poki


2011/5/3 Jan-Simon Möller 

> Am Dienstag, 3. Mai 2011, 11:13:35 schrieb 李柏舉:
> > arm-2007q3
>
> Try a newer cross-compiler please and then report back.
>
> Best,
> Jan-Simon
>


Re: [Qemu-devel] [PATCH 3/3] ide: add TRIM support

2011-05-04 Thread Kevin Wolf
Am 03.05.2011 14:06, schrieb Christoph Hellwig:
> Add support for TRIM sub function of the data set management command,
> and wire it up to the qemu discard infrastructure.
> 
> Signed-off-by: Christoph Hellwig 

Don't failed trim requests turn into writes now?

Also, there are some braces missing.

Kevin



Re: [Qemu-devel] [PATCH v3 5/5] hpet 'driftfix': add code in hpet_timer() to compensate delayed callbacks and coalesced interrupts

2011-05-04 Thread Marcelo Tosatti
On Wed, May 04, 2011 at 04:06:59AM -0400, Ulrich Obergfell wrote:
> 
> Hi Marcelo,
>  
> > Whats prev_period for, since in practice the period will not change
> > between interrupts (OS programs comparator once, or perhaps twice
> > during bootup) ?
> 
> 'prev_period' is needed if a guest o/s changes the comparator period
> 'on the fly' (without stopping and restarting the timer).
> 
> 
>  guest o/s changes period
>|
>   ti(n-1)  |ti(n)  ti(n+1)
> |  v  |  |
> +-+--+
> 
>  <--- prev_period ---> <-- period -->
> 
> 
> The idea is that each timer interrupt represents a certain quantum
> of time (the comparator period). If a guest o/s changes the period
> between timer interrupt 'n-1' and timer interrupt 'n', I think the
> new value should not take effect before timer interrupt 'n'. Timer
> interrupt 'n' still represents the old/previous quantum, and timer
> interrupt 'n+1' represents the new quantum.
> 
> Hence, the patch decrements 'ticks_not_accounted' by 'prev_period'
> and sets 'prev_period' to 'period' when an interrupt was delivered
> to the guest o/s.
> 
> +irq_delivered = update_irq(t, 1);
> +if (irq_delivered) {
> +t->ticks_not_accounted -= t->prev_period;
> +t->prev_period = t->period;
> +} else {
> 
> Most of the time 'prev_period' is equal to 'period'. It should only
> be different in the scenario shown above.

OK, makes sense. You should probably reset ticks_not_accounted to zero
on HPET initialization (for example, to avoid miscalibration when
kexec'ing a new kernel).




[Qemu-devel] [PATCH 03/13] s390x: make kvm exported functions conditional on kvm

2011-05-04 Thread Alexander Graf
We have some helper functions we use to directly invoke KVM
functionality from device emulation code.

This patch replaces those exported functions with static inline
stubs when not building with KVM enabled.

Signed-off-by: Alexander Graf 
---
 target-s390x/cpu.h |   17 +
 1 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/target-s390x/cpu.h b/target-s390x/cpu.h
index a84b3ee..79aa6c9 100644
--- a/target-s390x/cpu.h
+++ b/target-s390x/cpu.h
@@ -287,10 +287,27 @@ int cpu_s390x_handle_mmu_fault (CPUS390XState *env, 
target_ulong address, int rw
 #ifndef CONFIG_USER_ONLY
 int s390_virtio_hypercall(CPUState *env, uint64_t mem, uint64_t hypercall);
 
+#ifdef CONFIG_KVM
 void kvm_s390_interrupt(CPUState *env, int type, uint32_t code);
 void kvm_s390_virtio_irq(CPUState *env, int config_change, uint64_t token);
 void kvm_s390_interrupt_internal(CPUState *env, int type, uint32_t parm,
  uint64_t parm64, int vm);
+#else
+static inline void kvm_s390_interrupt(CPUState *env, int type, uint32_t code)
+{
+}
+
+static inline void kvm_s390_virtio_irq(CPUState *env, int config_change,
+   uint64_t token)
+{
+}
+
+static inline void kvm_s390_interrupt_internal(CPUState *env, int type,
+   uint32_t parm, uint64_t parm64,
+   int vm)
+{
+}
+#endif
 CPUState *s390_cpu_addr2state(uint16_t cpu_addr);
 
 #ifndef KVM_S390_SIGP_STOP
-- 
1.6.0.2




[Qemu-devel] [PATCH 05/13] s390x: Shift variables in CPUState for memset(0)

2011-05-04 Thread Alexander Graf
The default reset handler does a memset(0) until right in between CPU_COMMON.
I incorrectly changed that behavior on the s390x port, so let's move the fields
in CPUState around to reflect the correct split up to which point memset(0)
zeros out everything.

Signed-off-by: Alexander Graf 
---
 target-s390x/cpu.h |7 ---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/target-s390x/cpu.h b/target-s390x/cpu.h
index 00939a3..125b939 100644
--- a/target-s390x/cpu.h
+++ b/target-s390x/cpu.h
@@ -87,9 +87,12 @@ typedef struct CPUS390XState {
 int pending_int;
 ExtQueue ext_queue[MAX_EXT_QUEUE];
 
+int ext_index;
+
+CPU_COMMON
+
 /* reset does memset(0) up to here */
 
-int ext_index;
 int cpu_num;
 uint8_t *storage_keys;
 
@@ -98,8 +101,6 @@ typedef struct CPUS390XState {
 QEMUTimer *tod_timer;
 
 QEMUTimer *cpu_timer;
-
-CPU_COMMON
 } CPUS390XState;
 
 #if defined(CONFIG_USER_ONLY)
-- 
1.6.0.2




[Qemu-devel] [PATCH 01/13] tcg: extend max tcg opcodes when using 64-on-32bit

2011-05-04 Thread Alexander Graf
When running a 64 bit guest on a 32 bit host, we tend to use more TCG ops
than on a 64 bit host. Reflect that in the reserved opcode amount constant.

Signed-off-by: Alexander Graf 

---

v4 -> v5:

  - only increase MAX_OP_PER_INSTR when running 64-on-32
---
 exec-all.h |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/exec-all.h b/exec-all.h
index 7c2d29f..14b0895 100644
--- a/exec-all.h
+++ b/exec-all.h
@@ -43,7 +43,11 @@ typedef ram_addr_t tb_page_addr_t;
 typedef struct TranslationBlock TranslationBlock;
 
 /* XXX: make safe guess about sizes */
+#if (HOST_LONG_BITS == 32) && (TARGET_LONG_BITS == 64)
+#define MAX_OP_PER_INSTR 128
+#else
 #define MAX_OP_PER_INSTR 96
+#endif
 
 #if HOST_LONG_BITS == 32
 #define MAX_OPC_PARAM_PER_ARG 2
-- 
1.6.0.2




[Qemu-devel] [PATCH 08/13] s390x: Adjust internal kvm code

2011-05-04 Thread Alexander Graf
We're now finally emulating an s390x CPU, so we can move quite some logic
from the kvm code out into generic CPU code.

This patch does this and adjusts the interfaces according to what the code
around now expects to be able to call.

Signed-off-by: Alexander Graf 
---
 target-s390x/kvm.c |   44 +++-
 1 files changed, 7 insertions(+), 37 deletions(-)

diff --git a/target-s390x/kvm.c b/target-s390x/kvm.c
index 2643460..b68749b 100644
--- a/target-s390x/kvm.c
+++ b/target-s390x/kvm.c
@@ -49,13 +49,6 @@
 #define DIAG_KVM_HYPERCALL  0x500
 #define DIAG_KVM_BREAKPOINT 0x501
 
-#define SCP_LENGTH  0x00
-#define SCP_FUNCTION_CODE   0x02
-#define SCP_CONTROL_MASK0x03
-#define SCP_RESPONSE_CODE   0x06
-#define SCP_MEM_CODE0x08
-#define SCP_INCREMENT   0x0a
-
 #define ICPT_INSTRUCTION0x04
 #define ICPT_WAITPSW0x1c
 #define ICPT_SOFT_INTERCEPT 0x24
@@ -228,9 +221,9 @@ static void enter_pgmcheck(CPUState *env, uint16_t code)
 kvm_s390_interrupt(env, KVM_S390_PROGRAM_INT, code);
 }
 
-static void setcc(CPUState *env, uint64_t cc)
+static inline void setcc(CPUState *env, uint64_t cc)
 {
-env->kvm_run->psw_mask &= ~(3ul << 44);
+env->kvm_run->psw_mask &= ~(3ull << 44);
 env->kvm_run->psw_mask |= (cc & 3) << 44;
 
 env->psw.mask &= ~(3ul << 44);
@@ -248,35 +241,11 @@ static int kvm_sclp_service_call(CPUState *env, struct 
kvm_run *run,
 sccb = env->regs[ipbh0 & 0xf];
 code = env->regs[(ipbh0 & 0xf0) >> 4];
 
-dprintf("sclp(0x%x, 0x%lx)\n", sccb, code);
-
-if (sccb & ~0x7ff8ul) {
-fprintf(stderr, "KVM: invalid sccb address 0x%x\n", sccb);
-r = -1;
-goto out;
-}
-
-switch(code) {
-case SCLP_CMDW_READ_SCP_INFO:
-case SCLP_CMDW_READ_SCP_INFO_FORCED:
-stw_phys(sccb + SCP_MEM_CODE, ram_size >> 20);
-stb_phys(sccb + SCP_INCREMENT, 1);
-stw_phys(sccb + SCP_RESPONSE_CODE, 0x10);
-setcc(env, 0);
-
-kvm_s390_interrupt_internal(env, KVM_S390_INT_SERVICE,
-sccb & ~3, 0, 1);
-break;
-default:
-dprintf("KVM: invalid sclp call 0x%x / 0x%lx\n", sccb, code);
-r = -1;
-break;
-}
-
-out:
-if (r < 0) {
+r = sclp_service_call(env, sccb, code);
+if (r) {
 setcc(env, 3);
 }
+
 return 0;
 }
 
@@ -449,7 +418,8 @@ static int handle_intercept(CPUState *env)
 int icpt_code = run->s390_sieic.icptcode;
 int r = 0;
 
-dprintf("intercept: 0x%x (at 0x%lx)\n", icpt_code, env->kvm_run->psw_addr);
+dprintf("intercept: 0x%x (at 0x%lx)\n", icpt_code,
+(long)env->kvm_run->psw_addr);
 switch (icpt_code) {
 case ICPT_INSTRUCTION:
 r = handle_instruction(env, run);
-- 
1.6.0.2




[Qemu-devel] [PATCH 00/13] s390x emulation support v5

2011-05-04 Thread Alexander Graf
We've had support for running s390x guests with KVM for a
while now. This patch set also enables support for running
s390x guests in system as well as linux-user mode in emulation!

Within this scope, I again want to stress that this is _not_
supposed to replace Hercules - the s390 emulator - in any way.
The only target supported by qemu is Linux. You can only run
Linux applications with linux-user emulation and Linux guest OSs
with the system emulation. All the device logic (and 24 bit mode)
for running legacy stuff is missing. Use Hercules for those!

I have successfully run the following guest OSs:

  - SUSE Linux Enterprise Server 11 SP1
  - Debian Lenny

Both of which work just fine on x86_64 and ppc hosts. Other hosts
should also work. The only thing that did not work for me is network.
Somehow networking only works with KVM enabled, so there is probably
some bug involved still.

Either way - rejoice! As with this patch set you can finally fulfill
your mainframe desires on your local workstation. And - most importantly -
finally test patches to virtio against s390!

For images, I'm hoping for Aurelien to provide Debian images that run
in qemu. Other distributions only provide S390x target support in their
enterprise variants, keeping me from redistributing images :(.

If you're trying to get things rolling yourself, make sure to use a
recent kernel that has support for the virtio architecture and virtio
console support - otherwise you won't see output.

The linux user mode emulation part only support 64bit binaries, so
running Debian binaries with that one is out of question for now. Use
the system emulation mode if you really need to run Debian binaries.

For the lazy ones:

git://repo.or.cz/qemu/agraf.git s390-tcg-v5

v1 -> v2:

  - fix broken s390-virtio-serial
  - fix broken s390 kvm target
  - always set 64bit flag for s390x binaries in elf loader
  - remove redundant EXECUTE_SVC
  - advance psw.addr in syscall execution path
  - remove FPReg definition
  - add descriptions to more cc_ops
  - add comment on time2tod
  - describe EXCP_EXT
  - use new clock syntax
  - use float_chs
  - use float compare built-ins
  - remove redundant EXECUTE_SVC
  - don't pass env into DisasContext
  - remove if 0'd code
  - truncate at 80 chars
  - enable disas debug by default (-d in_asm)
  - remove explicit psw.addr advancing on SVC

v2 -> v3:

  - use g2h instead of direct casts
  - remove old code stuffed into comments
  - reduce amount of tcg ops in LM and LMH to stay below limits
  - add patch: fix virtio feature bitmap
  - add patch: set alignment for long to 8
  - add patch: use ext op for deposit

v3 -> v4:

  - move linux-user host bits to its own file, remove useless parts
  - add slag cc type
  - make patchset bisectable
  - declare non-working when EXT is masked
  - remove obsolete cpu_halted
  - enable RAM boundary check
  - implement slag, iilh, iill
  - fix icm cc
  - improve on 32bit hosts
  - coding style

v4 -> v5:

  - only increase MAX_OP_PER_INSTR when running 64-on-32
  - make virtio_size const
  - make macros be upper case
  - keep breakpoints as bzero seperator
  - remove printf hack
  - replace patch: kvm arch stub / export conditional functions in cpu.h
  - new patch: Shift variables in CPUState for memset(0)
  - new patch Fix debugging for unknown sigp order codes

Alexander Graf (11):
  tcg: extend max tcg opcodes when using 64-on-32bit
  s390x: make kvm exported functions conditional on kvm
  s390x: keep hint on virtio managing size
  s390x: Shift variables in CPUState for memset(0)
  s390x: helper functions for system emulation
  s390x: Implement opcode helpers
  s390x: Adjust internal kvm code
  s390x: translate engine for s390x CPU
  s390x: Adjust GDB stub
  s390x: remove compatibility cc field
  s390x: build s390x by default

Christian Borntraeger (1):
  s390x: Fix debugging for unknown sigp order codes

Ulrich Hecht (1):
  s390x: s390x-linux-user support

 configure|2 +
 default-configs/s390x-linux-user.mak |1 +
 exec-all.h   |4 +
 gdbstub.c|8 +-
 hw/s390-virtio-bus.c |3 +
 hw/s390-virtio-bus.h |2 +-
 linux-user/elfload.c |   19 +
 linux-user/main.c|   83 +
 linux-user/s390x/syscall.h   |   23 +
 linux-user/s390x/syscall_nr.h|  349 +++
 linux-user/s390x/target_signal.h |   26 +
 linux-user/s390x/termbits.h  |  283 ++
 linux-user/signal.c  |  333 +++
 linux-user/syscall.c |   16 +-
 linux-user/syscall_defs.h|   55 +-
 scripts/qemu-binfmt-conf.sh  |4 +-
 target-s390x/cpu.h   |   28 +-
 target-s390x/helper.c|  565 -
 target-s390x/helpers.h   |  151 +
 target-s390x/kvm.c   |   46 +-
 target-s390x/op_helper.c | 2925 +++-
 target-s390x/tra

[Qemu-devel] [PATCH 06/13] s390x: helper functions for system emulation

2011-05-04 Thread Alexander Graf
When running system emulation, we need to transverse through the MMU and
deliver interrupts according to the specification.

This patch implements those two pieces and in addition adjusts the CPU
initialization code to account for the new fields in CPUState.

Signed-off-by: Alexander Graf 

---

v1 -> v2:

  - new clock syntax

v3 -> v4:

  - enable RAM boundary check
  - bisectability

v4 -> v5:

  - make macros be upper case
  - keep breakpoints as bzero seperator
  - remove printf hack
---
 target-s390x/helper.c|  565 +-
 target-s390x/op_helper.c |6 +
 target-s390x/translate.c |4 +
 3 files changed, 565 insertions(+), 10 deletions(-)

diff --git a/target-s390x/helper.c b/target-s390x/helper.c
index 629dfd9..c79af46 100644
--- a/target-s390x/helper.c
+++ b/target-s390x/helper.c
@@ -2,6 +2,7 @@
  *  S/390 helpers
  *
  *  Copyright (c) 2009 Ulrich Hecht
+ *  Copyright (c) 2011 Alexander Graf
  *
  * This library is free software; you can redistribute it and/or
  * modify it under the terms of the GNU Lesser General Public
@@ -25,27 +26,107 @@
 #include "exec-all.h"
 #include "gdbstub.h"
 #include "qemu-common.h"
+#include "qemu-timer.h"
 
+#if !defined(CONFIG_USER_ONLY)
 #include 
 #include "kvm.h"
+#endif
+
+//#define DEBUG_S390
+//#define DEBUG_S390_PTE
+//#define DEBUG_S390_STDOUT
+
+#ifdef DEBUG_S390
+#ifdef DEBUG_S390_STDOUT
+#define DPRINTF(fmt, ...) \
+do { fprintf(stderr, fmt, ## __VA_ARGS__); \
+ qemu_log(fmt, ##__VA_ARGS__); } while (0)
+#else
+#define DPRINTF(fmt, ...) \
+do { qemu_log(fmt, ## __VA_ARGS__); } while (0)
+#endif
+#else
+#define DPRINTF(fmt, ...) \
+do { } while (0)
+#endif
+
+#ifdef DEBUG_S390_PTE
+#define PTE_DPRINTF DPRINTF
+#else
+#define PTE_DPRINTF(fmt, ...) \
+do { } while (0)
+#endif
+
+#ifndef CONFIG_USER_ONLY
+static void s390x_tod_timer(void *opaque)
+{
+CPUState *env = opaque;
+
+env->pending_int |= INTERRUPT_TOD;
+cpu_interrupt(env, CPU_INTERRUPT_HARD);
+}
+
+static void s390x_cpu_timer(void *opaque)
+{
+CPUState *env = opaque;
+
+env->pending_int |= INTERRUPT_CPUTIMER;
+cpu_interrupt(env, CPU_INTERRUPT_HARD);
+}
+#endif
 
 CPUS390XState *cpu_s390x_init(const char *cpu_model)
 {
 CPUS390XState *env;
+#if !defined (CONFIG_USER_ONLY)
+struct tm tm;
+#endif
 static int inited = 0;
+static int cpu_num = 0;
 
 env = qemu_mallocz(sizeof(CPUS390XState));
 cpu_exec_init(env);
 if (!inited) {
 inited = 1;
+s390x_translate_init();
 }
 
+#if !defined(CONFIG_USER_ONLY)
+qemu_get_timedate(&tm, 0);
+env->tod_offset = TOD_UNIX_EPOCH +
+  (time2tod(mktimegm(&tm)) * 10ULL);
+env->tod_basetime = 0;
+env->tod_timer = qemu_new_timer_ns(vm_clock, s390x_tod_timer, env);
+env->cpu_timer = qemu_new_timer_ns(vm_clock, s390x_cpu_timer, env);
+#endif
 env->cpu_model_str = cpu_model;
+env->cpu_num = cpu_num++;
+env->ext_index = -1;
 cpu_reset(env);
 qemu_init_vcpu(env);
 return env;
 }
 
+#if defined(CONFIG_USER_ONLY)
+
+void do_interrupt (CPUState *env)
+{
+env->exception_index = -1;
+}
+
+int cpu_s390x_handle_mmu_fault (CPUState *env, target_ulong address, int rw,
+  int mmu_idx, int is_softmmu)
+{
+/* fprintf(stderr,"%s: address 0x%lx rw %d mmu_idx %d is_softmmu %d\n",
+__FUNCTION__, address, rw, mmu_idx, is_softmmu); */
+env->exception_index = EXCP_ADDR;
+env->__excp_addr = address; /* FIXME: find out how this works on a real 
machine */
+return 1;
+}
+
+#endif /* CONFIG_USER_ONLY */
+
 void cpu_reset(CPUS390XState *env)
 {
 if (qemu_loglevel_mask(CPU_LOG_RESET)) {
@@ -58,31 +139,495 @@ void cpu_reset(CPUS390XState *env)
 tlb_flush(env, 1);
 }
 
-target_phys_addr_t cpu_get_phys_page_debug(CPUState *env, target_ulong addr)
+#ifndef CONFIG_USER_ONLY
+
+/* Ensure to exit the TB after this call! */
+static void trigger_pgm_exception(CPUState *env, uint32_t code, uint32_t ilc)
+{
+env->exception_index = EXCP_PGM;
+env->int_pgm_code = code;
+env->int_pgm_ilc = ilc;
+}
+
+static int trans_bits(CPUState *env, uint64_t mode)
+{
+int bits = 0;
+
+switch (mode) {
+case PSW_ASC_PRIMARY:
+bits = 1;
+break;
+case PSW_ASC_SECONDARY:
+bits = 2;
+break;
+case PSW_ASC_HOME:
+bits = 3;
+break;
+default:
+cpu_abort(env, "unknown asc mode\n");
+break;
+}
+
+return bits;
+}
+
+static void trigger_prot_fault(CPUState *env, target_ulong vaddr, uint64_t 
mode)
+{
+int ilc = ILC_LATER_INC_2;
+int bits = trans_bits(env, mode) | 4;
+
+DPRINTF("%s: vaddr=%016" PRIx64 " bits=%d\n", __FUNCTION__, vaddr, bits);
+
+stq_phys(env->psa + offsetof(LowCore, trans_exc_code), vaddr | bits);
+trigger_pgm_exception(env, PGM_PROTECTION, ilc);
+}
+
+static void trigger_page_fault(CPUState *env, target_ulong vaddr, uint32_t

[Qemu-devel] [PATCH 10/13] s390x: Adjust GDB stub

2011-05-04 Thread Alexander Graf
We have successfully lazilized cc computation, so we need to manually
trigger its calculation when gdb wants to fetch it. We also changed the
variable name, so writing it writes into a different field now.

Signed-off-by: Alexander Graf 
---
 gdbstub.c |8 ++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/gdbstub.c b/gdbstub.c
index 0838948..ae856f9 100644
--- a/gdbstub.c
+++ b/gdbstub.c
@@ -1436,7 +1436,11 @@ static int cpu_gdb_read_register(CPUState *env, uint8_t 
*mem_buf, int n)
 /* XXX */
 break;
 case S390_PC_REGNUM: GET_REGL(env->psw.addr); break;
-case S390_CC_REGNUM: GET_REG32(env->cc); break;
+case S390_CC_REGNUM:
+env->cc_op = calc_cc(env, env->cc_op, env->cc_src, env->cc_dst,
+ env->cc_vr);
+GET_REG32(env->cc_op);
+break;
 }
 
 return 0;
@@ -1462,7 +1466,7 @@ static int cpu_gdb_write_register(CPUState *env, uint8_t 
*mem_buf, int n)
 /* XXX */
 break;
 case S390_PC_REGNUM: env->psw.addr = tmpl; break;
-case S390_CC_REGNUM: env->cc = tmp32; r=4; break;
+case S390_CC_REGNUM: env->cc_op = tmp32; r=4; break;
 }
 
 return r;
-- 
1.6.0.2




[Qemu-devel] [PATCH 11/13] s390x: remove compatibility cc field

2011-05-04 Thread Alexander Graf
Remove the now unused cc field that was only required to not break
bisectability.

Signed-off-by: Alexander Graf 
---
 target-s390x/cpu.h |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/target-s390x/cpu.h b/target-s390x/cpu.h
index 125b939..4e5c391 100644
--- a/target-s390x/cpu.h
+++ b/target-s390x/cpu.h
@@ -67,7 +67,6 @@ typedef struct CPUS390XState {
 
 PSW psw;
 
-uint32_t cc;
 uint32_t cc_op;
 uint64_t cc_src;
 uint64_t cc_dst;
-- 
1.6.0.2




[Qemu-devel] [PATCH 02/13] s390x: s390x-linux-user support

2011-05-04 Thread Alexander Graf
From: Ulrich Hecht 

This patch adds support for running s390x binaries in the linux-user emulation
code.

Signed-off-by: Ulrich Hecht 
Signed-off-by: Alexander Graf 

---

v1 -> v2:

  - always set 64bit flag for s390x binaries in elf loader
  - remove redundant EXECUTE_SVC
  - advance psw.addr in syscall execution path

v3 -> v4:

  - fix 32bit hosts
  - fix coding style (except for header files shared with Linux)
---
 linux-user/elfload.c |   19 ++
 linux-user/main.c|   83 +
 linux-user/s390x/syscall.h   |   23 +++
 linux-user/s390x/syscall_nr.h|  349 ++
 linux-user/s390x/target_signal.h |   26 +++
 linux-user/s390x/termbits.h  |  283 ++
 linux-user/signal.c  |  333 
 linux-user/syscall.c |   16 ++-
 linux-user/syscall_defs.h|   55 ++-
 scripts/qemu-binfmt-conf.sh  |4 +-
 10 files changed, 1184 insertions(+), 7 deletions(-)
 create mode 100644 linux-user/s390x/syscall.h
 create mode 100644 linux-user/s390x/syscall_nr.h
 create mode 100644 linux-user/s390x/target_signal.h
 create mode 100644 linux-user/s390x/termbits.h

diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index 4c399f8..dcfeb7a 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -867,6 +867,25 @@ static inline void init_thread(struct target_pt_regs *regs,
 
 #endif /* TARGET_ALPHA */
 
+#ifdef TARGET_S390X
+
+#define ELF_START_MMAP (0x200ULL)
+
+#define elf_check_arch(x) ( (x) == ELF_ARCH )
+
+#define ELF_CLASS  ELFCLASS64
+#define ELF_DATA   ELFDATA2MSB
+#define ELF_ARCH   EM_S390
+
+static inline void init_thread(struct target_pt_regs *regs, struct image_info 
*infop)
+{
+regs->psw.addr = infop->entry;
+regs->psw.mask = PSW_MASK_64 | PSW_MASK_32;
+regs->gprs[15] = infop->start_stack;
+}
+
+#endif /* TARGET_S390X */
+
 #ifndef ELF_PLATFORM
 #define ELF_PLATFORM (NULL)
 #endif
diff --git a/linux-user/main.c b/linux-user/main.c
index a1e37e4..82aaf9d 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -2701,6 +2701,80 @@ void cpu_loop (CPUState *env)
 }
 #endif /* TARGET_ALPHA */
 
+#ifdef TARGET_S390X
+void cpu_loop(CPUS390XState *env)
+{
+int trapnr;
+target_siginfo_t info;
+
+while (1) {
+trapnr = cpu_s390x_exec (env);
+
+switch (trapnr) {
+case EXCP_INTERRUPT:
+/* just indicate that signals should be handled asap */
+break;
+case EXCP_DEBUG:
+{
+int sig;
+
+sig = gdb_handlesig (env, TARGET_SIGTRAP);
+if (sig) {
+info.si_signo = sig;
+info.si_errno = 0;
+info.si_code = TARGET_TRAP_BRKPT;
+queue_signal(env, info.si_signo, &info);
+}
+}
+break;
+case EXCP_SVC:
+{
+int n = env->int_svc_code;
+if (!n) {
+/* syscalls > 255 */
+n = env->regs[1];
+}
+env->psw.addr += env->int_svc_ilc;
+env->regs[2] = do_syscall(env, n,
+   env->regs[2],
+   env->regs[3],
+   env->regs[4],
+   env->regs[5],
+   env->regs[6],
+   env->regs[7]);
+}
+break;
+case EXCP_ADDR:
+{
+info.si_signo = SIGSEGV;
+info.si_errno = 0;
+/* XXX: check env->error_code */
+info.si_code = TARGET_SEGV_MAPERR;
+info._sifields._sigfault._addr = env->__excp_addr;
+queue_signal(env, info.si_signo, &info);
+}
+break;
+case EXCP_SPEC:
+{
+fprintf(stderr,"specification exception insn 0x%08x%04x\n", 
ldl(env->psw.addr), lduw(env->psw.addr + 4));
+info.si_signo = SIGILL;
+info.si_errno = 0;
+info.si_code = TARGET_ILL_ILLOPC;
+info._sifields._sigfault._addr = env->__excp_addr;
+queue_signal(env, info.si_signo, &info);
+}
+break;
+default:
+printf ("Unhandled trap: 0x%x\n", trapnr);
+cpu_dump_state(env, stderr, fprintf, 0);
+exit (1);
+}
+process_pending_signals (env);
+}
+}
+
+#endif /* TARGET_S390X */
+
 static void version(void)
 {
 printf("qemu-" TARGET_ARCH " version " QEMU_VERSION QEMU_PKGVERSION
@@ -3450,6 +3524,15 @@ int main(int argc, char **argv, char **envp)
env->regs[15] = regs->acr;  
env->pc = regs->erp;
 }
+#elif defined(TARGET_S390X)
+{
+int i;
+for (i = 0; i < 16; i++) {
+e

[Qemu-devel] [PATCH 04/13] s390x: keep hint on virtio managing size

2011-05-04 Thread Alexander Graf
The s390x virtio bus keeps management information on virtio after the top
of the guest's RAM. We need to be able to tell the guest the size of its
RAM (without virtio stuff), but also be able to trap when the guest accesses
RAM outside of its scope (including virtio stuff).

So we need a variable telling us the size of the virtio stuff, so we can
calculate the highest available RAM address from that.

While at it, also increase the maximum number of virtio pages, so we play
along well with more recent kernels that spawn a ridiculous number of virtio
console adapters.

Signed-off-by: Alexander Graf 

---

v4 -> v5:

  - make virtio_size const
---
 hw/s390-virtio-bus.c |3 +++
 hw/s390-virtio-bus.h |2 +-
 target-s390x/cpu.h   |3 +++
 3 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/hw/s390-virtio-bus.c b/hw/s390-virtio-bus.c
index bb49e39..d4a12f7 100644
--- a/hw/s390-virtio-bus.c
+++ b/hw/s390-virtio-bus.c
@@ -60,6 +60,9 @@ static const VirtIOBindings virtio_s390_bindings;
 
 static ram_addr_t s390_virtio_device_num_vq(VirtIOS390Device *dev);
 
+/* length of VirtIO device pages */
+const target_phys_addr_t virtio_size = S390_DEVICE_PAGES * TARGET_PAGE_SIZE;
+
 VirtIOS390Bus *s390_virtio_bus_init(ram_addr_t *ram_size)
 {
 VirtIOS390Bus *bus;
diff --git a/hw/s390-virtio-bus.h b/hw/s390-virtio-bus.h
index edf6d04..0c412d0 100644
--- a/hw/s390-virtio-bus.h
+++ b/hw/s390-virtio-bus.h
@@ -33,7 +33,7 @@
 #define VIRTIO_VQCONFIG_LEN24
 
 #define VIRTIO_RING_LEN(TARGET_PAGE_SIZE * 3)
-#define S390_DEVICE_PAGES  256
+#define S390_DEVICE_PAGES  512
 
 typedef struct VirtIOS390Device {
 DeviceState qdev;
diff --git a/target-s390x/cpu.h b/target-s390x/cpu.h
index 79aa6c9..00939a3 100644
--- a/target-s390x/cpu.h
+++ b/target-s390x/cpu.h
@@ -310,6 +310,9 @@ static inline void kvm_s390_interrupt_internal(CPUState 
*env, int type,
 #endif
 CPUState *s390_cpu_addr2state(uint16_t cpu_addr);
 
+/* from s390-virtio-bus */
+extern const target_phys_addr_t virtio_size;
+
 #ifndef KVM_S390_SIGP_STOP
 #define KVM_S390_SIGP_STOP  0
 #define KVM_S390_PROGRAM_INT0
-- 
1.6.0.2




[Qemu-devel] [PATCH 12/13] s390x: build s390x by default

2011-05-04 Thread Alexander Graf
This patch enables building of s390x-softmmu and s390x-linux-user
targets by default.

Signed-off-by: Alexander Graf 
---
 configure|2 ++
 default-configs/s390x-linux-user.mak |1 +
 2 files changed, 3 insertions(+), 0 deletions(-)
 create mode 100644 default-configs/s390x-linux-user.mak

diff --git a/configure b/configure
index 6f75e2e..6cdcdfe 100755
--- a/configure
+++ b/configure
@@ -1028,6 +1028,7 @@ sh4-softmmu \
 sh4eb-softmmu \
 sparc-softmmu \
 sparc64-softmmu \
+s390x-softmmu \
 "
 fi
 # the following are Linux specific
@@ -1053,6 +1054,7 @@ sparc-linux-user \
 sparc64-linux-user \
 sparc32plus-linux-user \
 unicore32-linux-user \
+s390x-linux-user \
 "
 fi
 # the following are Darwin specific
diff --git a/default-configs/s390x-linux-user.mak 
b/default-configs/s390x-linux-user.mak
new file mode 100644
index 000..a243c99
--- /dev/null
+++ b/default-configs/s390x-linux-user.mak
@@ -0,0 +1 @@
+# Default configuration for s390x-linux-user
-- 
1.6.0.2




[Qemu-devel] [PATCH 13/13] s390x: Fix debugging for unknown sigp order codes

2011-05-04 Thread Alexander Graf
From: Christian Borntraeger 

On unknown sigp order codes we print a debug message. This patch
fixes the output, since we want to see the order_code and not
the register numbers.
Patch applies on agraf tree.

Signed-off-by: Christian Borntraeger 
Signed-off-by: Alexander Graf 
---
 target-s390x/kvm.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/target-s390x/kvm.c b/target-s390x/kvm.c
index b68749b..bd2eca4 100644
--- a/target-s390x/kvm.c
+++ b/target-s390x/kvm.c
@@ -377,7 +377,7 @@ static int handle_sigp(CPUState *env, struct kvm_run *run, 
uint8_t ipa1)
 r = s390_cpu_initial_reset(target_env);
 break;
 default:
-fprintf(stderr, "KVM: unknown SIGP: 0x%x\n", ipa1);
+fprintf(stderr, "KVM: unknown SIGP: 0x%x\n", order_code);
 break;
 }
 
-- 
1.6.0.2




[Qemu-devel] [PATCH 2/2] Two new monitor commands: 'info keyboard', 'keyboard_set'

2011-05-04 Thread Dmitry Zhurikhin
From: Shahar Havivi 
Adding 2 new monitor commands to handle keyboard list:
'info keyboard' - show all keyboard devices and mark the current one
'keyboard_set'  - set active keyboard by index as displayed by 'info keyboard'

Signed-off-by: Shahar Havivi 
---
 console.h   |4 ++
 hmp-commands.hx |   20 ++
 input.c |  105 +++
 monitor.c   |8 
 4 files changed, 137 insertions(+), 0 deletions(-)

diff --git a/console.h b/console.h
index 671390c..c7cb017 100644
--- a/console.h
+++ b/console.h
@@ -90,6 +90,10 @@ void do_info_mice_print(Monitor *mon, const QObject *data);
 void do_info_mice(Monitor *mon, QObject **ret_data);
 void do_mouse_set(Monitor *mon, const QDict *qdict);
 
+void do_info_keyboard_print(Monitor *mon, const QObject *data);
+void do_info_keyboard(Monitor *mon, QObject **ret_data);
+int do_keyboard_set(Monitor *mon, const QDict *qdict, QObject **ret_data);
+
 /* keysym is a unicode code except for special keys (see QEMU_KEY_xxx
constants) */
 #define QEMU_KEY_ESC1(c) ((c) | 0xe100)
diff --git a/hmp-commands.hx b/hmp-commands.hx
index 834e6a8..0a71225 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -647,6 +647,24 @@ info mice
 @end example
 ETEXI
 
+{
+.name   = "keyboard_set",
+.args_type  = "index:i",
+.params = "index",
+.help   = "set which keyboard device receives events",
+.mhandler.cmd_new = do_keyboard_set,
+},
+
+STEXI
+@item keyboard_set @var{index}
+@findex keyboard_set
+Set which keyboard device receives events at given @var{index}, index
+can be obtained with
+@example
+info keyboard
+@end example
+ETEXI
+
 #ifdef HAS_AUDIO
 {
 .name   = "wavcapture",
@@ -1332,6 +1350,8 @@ show the current VM status (running|paused)
 show guest PCMCIA status
 @item info mice
 show which guest mouse is receiving events
+@item info keyboard
+show which guest keyboard is receiving events
 @item info vnc
 show the vnc server status
 @item info name
diff --git a/input.c b/input.c
index efec56e..6590bfb 100644
--- a/input.c
+++ b/input.c
@@ -317,3 +317,108 @@ void qemu_remove_mouse_mode_change_notifier(Notifier 
*notify)
 {
 notifier_list_remove(&mouse_mode_notifiers, notify);
 }
+
+static void info_keyboard_iter(QObject *data, void *opaque)
+{
+QDict *kbd;
+Monitor *mon = opaque;
+
+kbd = qobject_to_qdict(data);
+monitor_printf(mon, "%c Keyboard #%" PRId64 ": %s\n",
+  (qdict_get_bool(kbd, "current") ? '*' : ' '),
+  qdict_get_int(kbd, "index"), qdict_get_str(kbd, "name"));
+}
+
+void do_info_keyboard_print(Monitor *mon, const QObject *data)
+{
+QList *kbd_list;
+
+kbd_list = qobject_to_qlist(data);
+if (qlist_empty(kbd_list)) {
+monitor_printf(mon, "No keyboard devices connected\n");
+return;
+}
+
+qlist_iter(kbd_list, info_keyboard_iter, mon);
+}
+
+/*
+ * do_info_keyboard(): Show VM keyboard information
+ *
+ * Each keyboard is represented by a QDict, the returned QObject is
+ * a QList of all keyboards.
+ *
+ * The keyboard QDict contains the following:
+ *
+ * - "name": keyboard's name
+ * - "index": keyboard's index
+ * - "current": true if this keyboard is receiving events, false otherwise
+ *
+ * Example:
+ *
+ * [ { "name": "QEMU USB Keyboard", "index": 0, "current": false },
+ *   { "name": "QEMU PS/2 Keyboard", "index": 1, "current": true } ]
+ */
+void do_info_keyboard(Monitor *mon, QObject **ret_data)
+{
+QEMUPutKbdEntry *cursor;
+QList *kbd_list;
+int current;
+
+kbd_list = qlist_new();
+
+if (QTAILQ_EMPTY(&kbd_handlers)) {
+goto out;
+}
+
+current = QTAILQ_FIRST(&kbd_handlers)->index;
+QTAILQ_FOREACH(cursor, &kbd_handlers, node) {
+QObject *obj;
+obj = qobject_from_jsonf("{ 'name': %s,"
+ "  'index': %d,"
+ "  'current': %i }",
+ cursor->qemu_put_kbd_name,
+ cursor->index,
+ current == cursor->index);
+qlist_append_obj(kbd_list, obj);
+}
+out:
+*ret_data = QOBJECT(kbd_list);
+}
+
+/*
+ * do_keyboard_set(): Set active keyboard
+ *
+ * Argument qdict contains
+ * - "index": the keyboard index to set
+ *
+ * Example:
+ *
+ * { "index": "0" }
+ */
+int do_keyboard_set(Monitor *mon, const QDict *qdict, QObject **ret_data)
+{
+QEMUPutKbdEntry *cursor;
+int index = qdict_get_int(qdict, "index");
+int found = 0;
+
+if (QTAILQ_EMPTY(&kbd_handlers)) {
+qerror_report(QERR_DEVICE_NOT_FOUND, "keyboard");
+return -1;
+}
+
+QTAILQ_FOREACH(cursor, &kbd_handlers, node) {
+if (cursor->index == index) {
+qemu_activate_keyboard_event_handler(cursor);
+found = 1;
+break;
+}
+}
+
+if (!found) {
+qerror_report(QERR_INVALID

[Qemu-devel] [PATCH 0/2 v6] Qemu support for multiple keyboard devices

2011-05-04 Thread Dmitry Zhurikhin
v6 (Dmitry Zhurikhin ):
- merge with commit 57aa265d462a64a06268be26d49020729cff56c1
- moved changes from usb-hid.c and qemu_activate_keyboard_event_handler function
  to the first patch as more appropriate
- changed some keyboard names to be more consistent
- added 'info keyboard' to the 'info subcommand' documentation chapter
- fixed an 'avoid assignment of zero to static variable' warning by
  'scripts/checkpatch.pl'


Qemu support for multiple keyboard devices:
Patch #1
Adding keyboard is done to the queue instead of "last added keyboard wins",
when removing keyboard via device_del - previous keyboard is selected.

Patch #2
Adding 2 new monitor commands to handle keyboard list:
'info keyboard' - show all keyboard devices and mark the current one
'keyboard_set'  - set active keyboard by index as displayed by 'info keyboard'

Shahar Havivi (2):
  Support for multiple keyboard devices
  Two new monitor commands: 'info keyboard', 'keyboard_set'

 console.h|   20 +-
 hmp-commands.hx  |   20 ++
 hw/adb.c |2 +-
 hw/escc.c|3 +-
 hw/musicpal.c|2 +-
 hw/nseries.c |4 +-
 hw/palm.c|2 +-
 hw/ps2.c |2 +-
 hw/pxa2xx_keypad.c   |3 +-
 hw/spitz.c   |3 +-
 hw/stellaris_input.c |3 +-
 hw/syborg_keyboard.c |3 +-
 hw/usb-hid.c |   12 +++-
 hw/xenfb.c   |5 +-
 input.c  |  168 +-
 monitor.c|8 +++
 16 files changed, 227 insertions(+), 33 deletions(-)




[Qemu-devel] [PATCH 1/2] Support for multiple keyboard devices

2011-05-04 Thread Dmitry Zhurikhin
From: Shahar Havivi 
Adding keyboard is done to the queue instead of "last added keyboard wins",
when removing keyboard via device_del - previous keyboard is selected.

Signed-off-by: Shahar Havivi 
---
 console.h|   16 +++-
 hw/adb.c |2 +-
 hw/escc.c|3 +-
 hw/musicpal.c|2 +-
 hw/nseries.c |4 +-
 hw/palm.c|2 +-
 hw/ps2.c |2 +-
 hw/pxa2xx_keypad.c   |3 +-
 hw/spitz.c   |3 +-
 hw/stellaris_input.c |3 +-
 hw/syborg_keyboard.c |3 +-
 hw/usb-hid.c |   12 -
 hw/xenfb.c   |5 ++-
 input.c  |   63 +
 14 files changed, 90 insertions(+), 33 deletions(-)

diff --git a/console.h b/console.h
index 64d1f09..671390c 100644
--- a/console.h
+++ b/console.h
@@ -43,8 +43,20 @@ typedef struct QEMUPutLEDEntry {
 QTAILQ_ENTRY(QEMUPutLEDEntry) next;
 } QEMUPutLEDEntry;
 
-void qemu_add_kbd_event_handler(QEMUPutKBDEvent *func, void *opaque);
-void qemu_remove_kbd_event_handler(void);
+typedef struct QEMUPutKbdEntry {
+char *qemu_put_kbd_name;
+QEMUPutKBDEvent *qemu_put_kbd_event;
+void *qemu_put_kbd_event_opaque;
+int index;
+
+QTAILQ_ENTRY(QEMUPutKbdEntry) node;
+} QEMUPutKbdEntry;
+
+QEMUPutKbdEntry *qemu_add_kbd_event_handler(QEMUPutKBDEvent *func,
+void *opaque,
+const char *name);
+void qemu_remove_kbd_event_handler(QEMUPutKbdEntry *entry);
+void qemu_activate_keyboard_event_handler(QEMUPutKbdEntry *entry);
 QEMUPutMouseEntry *qemu_add_mouse_event_handler(QEMUPutMouseEvent *func,
 void *opaque, int absolute,
 const char *name);
diff --git a/hw/adb.c b/hw/adb.c
index 7499cdc..7af5a0e 100644
--- a/hw/adb.c
+++ b/hw/adb.c
@@ -293,7 +293,7 @@ void adb_kbd_init(ADBBusState *bus)
 s = qemu_mallocz(sizeof(KBDState));
 d = adb_register_device(bus, ADB_KEYBOARD, adb_kbd_request,
 adb_kbd_reset, s);
-qemu_add_kbd_event_handler(adb_kbd_put_keycode, d);
+qemu_add_kbd_event_handler(adb_kbd_put_keycode, d, "QEMU ADB Keyboard");
 vmstate_register(NULL, -1, &vmstate_adb_kbd, s);
 }
 
diff --git a/hw/escc.c b/hw/escc.c
index f6fd919..d5d3297 100644
--- a/hw/escc.c
+++ b/hw/escc.c
@@ -928,7 +928,8 @@ static int escc_init1(SysBusDevice *dev)
  "QEMU Sun Mouse");
 }
 if (s->chn[1].type == kbd) {
-qemu_add_kbd_event_handler(sunkbd_event, &s->chn[1]);
+qemu_add_kbd_event_handler(sunkbd_event, &s->chn[1],
+   "QEMU Sun Keyboard");
 }
 
 return 0;
diff --git a/hw/musicpal.c b/hw/musicpal.c
index 52b2931..723f94b 100644
--- a/hw/musicpal.c
+++ b/hw/musicpal.c
@@ -1454,7 +1454,7 @@ static int musicpal_key_init(SysBusDevice *dev)
 
 qdev_init_gpio_out(&dev->qdev, s->out, ARRAY_SIZE(s->out));
 
-qemu_add_kbd_event_handler(musicpal_key_event, s);
+qemu_add_kbd_event_handler(musicpal_key_event, s, "QEMU Musicpal 
Keyboard");
 
 return 0;
 }
diff --git a/hw/nseries.c b/hw/nseries.c
index 2f6f473..5a4e0e8 100644
--- a/hw/nseries.c
+++ b/hw/nseries.c
@@ -262,7 +262,7 @@ static void n800_tsc_kbd_setup(struct n800_s *s)
 if (n800_keys[i] >= 0)
 s->keymap[n800_keys[i]] = i;
 
-qemu_add_kbd_event_handler(n800_key_event, s);
+qemu_add_kbd_event_handler(n800_key_event, s, "QEMU Nokia N800 Keyboard");
 
 tsc210x_set_transform(s->ts.chip, &n800_pointercal);
 }
@@ -371,7 +371,7 @@ static void n810_kbd_setup(struct n800_s *s)
 if (n810_keys[i] > 0)
 s->keymap[n810_keys[i]] = i;
 
-qemu_add_kbd_event_handler(n810_key_event, s);
+qemu_add_kbd_event_handler(n810_key_event, s, "QEMU Nokia N810 Keyboard");
 
 /* Attach the LM8322 keyboard to the I2C bus,
  * should happen in n8x0_i2c_setup and s->kbd be initialised here.  */
diff --git a/hw/palm.c b/hw/palm.c
index f22d777..ab60452 100644
--- a/hw/palm.c
+++ b/hw/palm.c
@@ -232,7 +232,7 @@ static void palmte_init(ram_addr_t ram_size,
 
 palmte_microwire_setup(cpu);
 
-qemu_add_kbd_event_handler(palmte_button_event, cpu);
+qemu_add_kbd_event_handler(palmte_button_event, cpu, "QEMU Palm Keyboard");
 
 palmte_gpio_setup(cpu);
 
diff --git a/hw/ps2.c b/hw/ps2.c
index 91b73e0..b12a76f 100644
--- a/hw/ps2.c
+++ b/hw/ps2.c
@@ -610,7 +610,7 @@ void *ps2_kbd_init(void (*update_irq)(void *, int), void 
*update_arg)
 s->common.update_arg = update_arg;
 s->scancode_set = 2;
 vmstate_register(NULL, 0, &vmstate_ps2_keyboard, s);
-qemu_add_kbd_event_handler(ps2_put_keycode, s);
+qemu_add_kbd_event_handler(ps2_put_keycode, s, "QEMU PS/2 Keyboard");
 qemu_register_reset(ps2_kbd_reset, s);
 return s;
 }
diff --git a/hw/pxa2xx_keypad.c b/hw/pxa2xx_key

Re: [Qemu-devel] [PATCH v3 5/5] hpet 'driftfix': add code in hpet_timer() to compensate delayed callbacks and coalesced interrupts

2011-05-04 Thread Glauber Costa
On Wed, 2011-05-04 at 06:09 -0300, Marcelo Tosatti wrote:
> On Wed, May 04, 2011 at 04:06:59AM -0400, Ulrich Obergfell wrote:
> > 
> > Hi Marcelo,
> >  
> > > Whats prev_period for, since in practice the period will not change
> > > between interrupts (OS programs comparator once, or perhaps twice
> > > during bootup) ?
> > 
> > 'prev_period' is needed if a guest o/s changes the comparator period
> > 'on the fly' (without stopping and restarting the timer).
> > 
> > 
> >  guest o/s changes period
> >|
> >   ti(n-1)  |ti(n)  ti(n+1)
> > |  v  |  |
> > +-+--+
> > 
> >  <--- prev_period ---> <-- period -->
> > 
> > 
> > The idea is that each timer interrupt represents a certain quantum
> > of time (the comparator period). If a guest o/s changes the period
> > between timer interrupt 'n-1' and timer interrupt 'n', I think the
> > new value should not take effect before timer interrupt 'n'. Timer
> > interrupt 'n' still represents the old/previous quantum, and timer
> > interrupt 'n+1' represents the new quantum.
> > 
> > Hence, the patch decrements 'ticks_not_accounted' by 'prev_period'
> > and sets 'prev_period' to 'period' when an interrupt was delivered
> > to the guest o/s.
> > 
> > +irq_delivered = update_irq(t, 1);
> > +if (irq_delivered) {
> > +t->ticks_not_accounted -= t->prev_period;
> > +t->prev_period = t->period;
> > +} else {
> > 
> > Most of the time 'prev_period' is equal to 'period'. It should only
> > be different in the scenario shown above.
> 
> OK, makes sense. You should probably reset ticks_not_accounted to zero
> on HPET initialization (for example, to avoid miscalibration when
> kexec'ing a new kernel).

Everybody resetting the machine in anyway is expected to force devices
to be reinitialized, right ?
I may be wrong, but I was under the impression that kexec would do this
as well. In this case, the reset function should be enough.





Re: [Qemu-devel] [PATCH] ide: cleanup warnings

2011-05-04 Thread Andrea Arcangeli
On Wed, May 04, 2011 at 10:08:12AM +0200, Kevin Wolf wrote:
> Isn't it a bug that qemu_aio_flush() doesn't clear aiocb/status? Should
> we move the ide_set_inactive() call from ide_dma_error to ide_dma_cb?

How would that make a difference, it's still running in aio context,
running it a bit earlier won't move the needle? I think it's more
likely an error path currently not covered by ide_set_inactive that
may have to be covered. It doesn't seem fatal but I tend to agree if
we can make that warning go away without putting it under #ifdef like
usptream, we should do that too.

Maybe something like this will make it go away?

diff --git a/hw/ide/core.c b/hw/ide/core.c
index 90f553b..b81f1d7 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -377,6 +377,7 @@ void ide_set_sector(IDEState *s, int64_t sector_num)
 
 static void ide_rw_error(IDEState *s) {
 ide_abort_command(s);
+ide_set_inactive(s);
 ide_set_irq(s->bus);
 }
 



Re: [Qemu-devel] [PATCH v3 5/5] hpet 'driftfix': add code in hpet_timer() to compensate delayed callbacks and coalesced interrupts

2011-05-04 Thread Gleb Natapov
On Wed, May 04, 2011 at 10:36:12AM -0300, Glauber Costa wrote:
> On Wed, 2011-05-04 at 06:09 -0300, Marcelo Tosatti wrote:
> > On Wed, May 04, 2011 at 04:06:59AM -0400, Ulrich Obergfell wrote:
> > > 
> > > Hi Marcelo,
> > >  
> > > > Whats prev_period for, since in practice the period will not change
> > > > between interrupts (OS programs comparator once, or perhaps twice
> > > > during bootup) ?
> > > 
> > > 'prev_period' is needed if a guest o/s changes the comparator period
> > > 'on the fly' (without stopping and restarting the timer).
> > > 
> > > 
> > >  guest o/s changes period
> > >|
> > >   ti(n-1)  |ti(n)  ti(n+1)
> > > |  v  |  |
> > > +-+--+
> > > 
> > >  <--- prev_period ---> <-- period -->
> > > 
> > > 
> > > The idea is that each timer interrupt represents a certain quantum
> > > of time (the comparator period). If a guest o/s changes the period
> > > between timer interrupt 'n-1' and timer interrupt 'n', I think the
> > > new value should not take effect before timer interrupt 'n'. Timer
> > > interrupt 'n' still represents the old/previous quantum, and timer
> > > interrupt 'n+1' represents the new quantum.
> > > 
> > > Hence, the patch decrements 'ticks_not_accounted' by 'prev_period'
> > > and sets 'prev_period' to 'period' when an interrupt was delivered
> > > to the guest o/s.
> > > 
> > > +irq_delivered = update_irq(t, 1);
> > > +if (irq_delivered) {
> > > +t->ticks_not_accounted -= t->prev_period;
> > > +t->prev_period = t->period;
> > > +} else {
> > > 
> > > Most of the time 'prev_period' is equal to 'period'. It should only
> > > be different in the scenario shown above.
> > 
> > OK, makes sense. You should probably reset ticks_not_accounted to zero
> > on HPET initialization (for example, to avoid miscalibration when
> > kexec'ing a new kernel).
> 
> Everybody resetting the machine in anyway is expected to force devices
> to be reinitialized, right ?
> I may be wrong, but I was under the impression that kexec would do this
> as well. In this case, the reset function should be enough.
> 
kexec does not reset a machine. That's the whole point of kexec in
fact.

--
Gleb.



Re: [Qemu-devel] [PATCH v3 5/5] hpet 'driftfix': add code in hpet_timer() to compensate delayed callbacks and coalesced interrupts

2011-05-04 Thread Glauber Costa
On Wed, 2011-05-04 at 16:46 +0300, Gleb Natapov wrote:
> On Wed, May 04, 2011 at 10:36:12AM -0300, Glauber Costa wrote:
> > On Wed, 2011-05-04 at 06:09 -0300, Marcelo Tosatti wrote:
> > > On Wed, May 04, 2011 at 04:06:59AM -0400, Ulrich Obergfell wrote:
> > > > 
> > > > Hi Marcelo,
> > > >  
> > > > > Whats prev_period for, since in practice the period will not change
> > > > > between interrupts (OS programs comparator once, or perhaps twice
> > > > > during bootup) ?
> > > > 
> > > > 'prev_period' is needed if a guest o/s changes the comparator period
> > > > 'on the fly' (without stopping and restarting the timer).
> > > > 
> > > > 
> > > >  guest o/s changes period
> > > >|
> > > >   ti(n-1)  |ti(n)  ti(n+1)
> > > > |  v  |  |
> > > > +-+--+
> > > > 
> > > >  <--- prev_period ---> <-- period -->
> > > > 
> > > > 
> > > > The idea is that each timer interrupt represents a certain quantum
> > > > of time (the comparator period). If a guest o/s changes the period
> > > > between timer interrupt 'n-1' and timer interrupt 'n', I think the
> > > > new value should not take effect before timer interrupt 'n'. Timer
> > > > interrupt 'n' still represents the old/previous quantum, and timer
> > > > interrupt 'n+1' represents the new quantum.
> > > > 
> > > > Hence, the patch decrements 'ticks_not_accounted' by 'prev_period'
> > > > and sets 'prev_period' to 'period' when an interrupt was delivered
> > > > to the guest o/s.
> > > > 
> > > > +irq_delivered = update_irq(t, 1);
> > > > +if (irq_delivered) {
> > > > +t->ticks_not_accounted -= t->prev_period;
> > > > +t->prev_period = t->period;
> > > > +} else {
> > > > 
> > > > Most of the time 'prev_period' is equal to 'period'. It should only
> > > > be different in the scenario shown above.
> > > 
> > > OK, makes sense. You should probably reset ticks_not_accounted to zero
> > > on HPET initialization (for example, to avoid miscalibration when
> > > kexec'ing a new kernel).
> > 
> > Everybody resetting the machine in anyway is expected to force devices
> > to be reinitialized, right ?
> > I may be wrong, but I was under the impression that kexec would do this
> > as well. In this case, the reset function should be enough.
> > 
> kexec does not reset a machine. That's the whole point of kexec in
> fact.
Sure thing, but doesn't it force the initialization routine of the devices 
themselves, without
going through the bios ?

> --
>   Gleb.





Re: [Qemu-devel] [PATCH] ide: cleanup warnings

2011-05-04 Thread Kevin Wolf
Am 04.05.2011 15:41, schrieb Andrea Arcangeli:
> On Wed, May 04, 2011 at 10:08:12AM +0200, Kevin Wolf wrote:
>> Isn't it a bug that qemu_aio_flush() doesn't clear aiocb/status? Should
>> we move the ide_set_inactive() call from ide_dma_error to ide_dma_cb?
> 
> How would that make a difference, it's still running in aio context,
> running it a bit earlier won't move the needle?

Yes, sorry, you're right. I was thinking of the werror=stop case, but
this isn't your case and ide_set_inactive would even be wrong there.

> I think it's more
> likely an error path currently not covered by ide_set_inactive that
> may have to be covered. It doesn't seem fatal but I tend to agree if
> we can make that warning go away without putting it under #ifdef like
> usptream, we should do that too.
> 
> Maybe something like this will make it go away?
> 
> diff --git a/hw/ide/core.c b/hw/ide/core.c
> index 90f553b..b81f1d7 100644
> --- a/hw/ide/core.c
> +++ b/hw/ide/core.c
> @@ -377,6 +377,7 @@ void ide_set_sector(IDEState *s, int64_t sector_num)
>  
>  static void ide_rw_error(IDEState *s) {
>  ide_abort_command(s);
> +ide_set_inactive(s);
>  ide_set_irq(s->bus);
>  }

No, this looks wrong. ide_rw_error is only used for PIO, and
ide_set_inactive() resets the DMA status.

I can't see how you could leave ide_dma_cb without either scheduling
another AIO request or setting aiocb = NULL in ide_set_inactive. I guess
I need to reproduce this and do some debugging...

Kevin



Re: [Qemu-devel] [PATCH v3 5/5] hpet 'driftfix': add code in hpet_timer() to compensate delayed callbacks and coalesced interrupts

2011-05-04 Thread Gleb Natapov
On Wed, May 04, 2011 at 10:47:40AM -0300, Glauber Costa wrote:
> On Wed, 2011-05-04 at 16:46 +0300, Gleb Natapov wrote:
> > On Wed, May 04, 2011 at 10:36:12AM -0300, Glauber Costa wrote:
> > > On Wed, 2011-05-04 at 06:09 -0300, Marcelo Tosatti wrote:
> > > > On Wed, May 04, 2011 at 04:06:59AM -0400, Ulrich Obergfell wrote:
> > > > > 
> > > > > Hi Marcelo,
> > > > >  
> > > > > > Whats prev_period for, since in practice the period will not change
> > > > > > between interrupts (OS programs comparator once, or perhaps twice
> > > > > > during bootup) ?
> > > > > 
> > > > > 'prev_period' is needed if a guest o/s changes the comparator period
> > > > > 'on the fly' (without stopping and restarting the timer).
> > > > > 
> > > > > 
> > > > >  guest o/s changes period
> > > > >|
> > > > >   ti(n-1)  |ti(n)  ti(n+1)
> > > > > |  v  |  |
> > > > > +-+--+
> > > > > 
> > > > >  <--- prev_period ---> <-- period -->
> > > > > 
> > > > > 
> > > > > The idea is that each timer interrupt represents a certain quantum
> > > > > of time (the comparator period). If a guest o/s changes the period
> > > > > between timer interrupt 'n-1' and timer interrupt 'n', I think the
> > > > > new value should not take effect before timer interrupt 'n'. Timer
> > > > > interrupt 'n' still represents the old/previous quantum, and timer
> > > > > interrupt 'n+1' represents the new quantum.
> > > > > 
> > > > > Hence, the patch decrements 'ticks_not_accounted' by 'prev_period'
> > > > > and sets 'prev_period' to 'period' when an interrupt was delivered
> > > > > to the guest o/s.
> > > > > 
> > > > > +irq_delivered = update_irq(t, 1);
> > > > > +if (irq_delivered) {
> > > > > +t->ticks_not_accounted -= t->prev_period;
> > > > > +t->prev_period = t->period;
> > > > > +} else {
> > > > > 
> > > > > Most of the time 'prev_period' is equal to 'period'. It should only
> > > > > be different in the scenario shown above.
> > > > 
> > > > OK, makes sense. You should probably reset ticks_not_accounted to zero
> > > > on HPET initialization (for example, to avoid miscalibration when
> > > > kexec'ing a new kernel).
> > > 
> > > Everybody resetting the machine in anyway is expected to force devices
> > > to be reinitialized, right ?
> > > I may be wrong, but I was under the impression that kexec would do this
> > > as well. In this case, the reset function should be enough.
> > > 
> > kexec does not reset a machine. That's the whole point of kexec in
> > fact.
> Sure thing, but doesn't it force the initialization routine of the devices 
> themselves, without
> going through the bios ?
> 
It just starts new kernel. New kernel's init runs as usual and
re-initialize everything. No it doesn't go through the BIOS. What for?
Actually I happily use kexec on IBM blade server where BIOS run takes no
less then 5 minutes and kexec reboots instantly.

--
Gleb.



Re: [Qemu-devel] [PATCH] ide: cleanup warnings

2011-05-04 Thread Andrea Arcangeli
On Wed, May 04, 2011 at 03:57:28PM +0200, Kevin Wolf wrote:
> I can't see how you could leave ide_dma_cb without either scheduling
> another AIO request or setting aiocb = NULL in ide_set_inactive. I guess
> I need to reproduce this and do some debugging...

That would be nice to be sure. This has been triggering on a older
codebase, it's uncertain if this would happen with current code
too. The \n so far was the only obvious improvement I could make to
the upstream code, until we understand better what's going on...

The good thing is it doesn't seem to cause problems, other than the
printf. The leftover in the dma->aiocb likely gets overwritten when
guest retries without failure.



Re: [Qemu-devel] [PATCH] ide: cleanup warnings

2011-05-04 Thread Kevin Wolf
Am 04.05.2011 16:04, schrieb Andrea Arcangeli:
> On Wed, May 04, 2011 at 03:57:28PM +0200, Kevin Wolf wrote:
>> I can't see how you could leave ide_dma_cb without either scheduling
>> another AIO request or setting aiocb = NULL in ide_set_inactive. I guess
>> I need to reproduce this and do some debugging...
> 
> That would be nice to be sure. This has been triggering on a older
> codebase, it's uncertain if this would happen with current code
> too. The \n so far was the only obvious improvement I could make to
> the upstream code, until we understand better what's going on...
> 
> The good thing is it doesn't seem to cause problems, other than the
> printf. The leftover in the dma->aiocb likely gets overwritten when
> guest retries without failure.

Right. I'm not so much concerned about aiocb (though it would certainly
be cleaner if we cleared it; I think it's checked in more places), but
more about bm->status which is a guest-visible register.

On the other hand we store things in bm->status that are definitely not
meant to be guest visible, so the emulation of this register is broken
anyway. Fixing all of this might turn out to be hard if you don't want
to break migration.

Kevin



[Qemu-devel] [PATCH v4 09/10] trace-state: [stderr] add support for dynamically enabling/disabling events

2011-05-04 Thread Lluís
Re-send patch with added minor fix.

Uses the generic interface provided in "trace/control.h" in order to provide
a programmatic interface as well as command line and monitor controls.

Signed-off-by: Fabien Chouteau 
Signed-off-by: Lluís Vilanova 
---
 configure |3 +++
 docs/tracing.txt  |5 -
 scripts/tracetool |   33 -
 trace/control.c   |4 ++--
 trace/stderr.h|   11 +++
 5 files changed, 44 insertions(+), 12 deletions(-)
 create mode 100644 trace/stderr.h

diff --git a/configure b/configure
index fef7d35..1da2df4 100755
--- a/configure
+++ b/configure
@@ -2950,6 +2950,9 @@ if test "$trace_backend" = "nop"; then
 elif test "$trace_backend" = "simple"; then
   echo "CONFIG_SIMPLE_TRACE=y" >> $config_host_mak
 fi
+if test "$trace_backend" = "stderr"; then
+  echo "CONFIG_TRACE_STDERR=y" >> $config_host_mak
+fi
 # Set the appropriate trace file.
 if test "$trace_backend" = "simple"; then
   trace_file="\"$trace_file-%u\""
diff --git a/docs/tracing.txt b/docs/tracing.txt
index c443171..9c17497 100644
--- a/docs/tracing.txt
+++ b/docs/tracing.txt
@@ -163,11 +163,6 @@ effectively turns trace events into debug printfs.
 This is the simplest backend and can be used together with existing code that
 uses DPRINTF().
 
-Note that with this backend trace events cannot be programmatically
-enabled/disabled. Thus, in order to trim down the amount of output and the
-performance impact of tracing, you might want to add the "disable" property in
-the "trace-events" file for those events you are not interested in.
-
 === Simpletrace ===
 
 The "simple" backend supports common use cases and comes as part of the QEMU
diff --git a/scripts/tracetool b/scripts/tracetool
index c740080..743d246 100755
--- a/scripts/tracetool
+++ b/scripts/tracetool
@@ -241,7 +241,12 @@ linetoh_begin_stderr()
 {
 cat <
+#include "trace/stderr.h"
+
+extern TraceEvent trace_list[];
 EOF
+
+stderr_event_num=0
 }
 
 linetoh_stderr()
@@ -260,29 +265,47 @@ linetoh_stderr()
 cat <

[Qemu-devel] [Bug 723871] Re: qemu-kvm-0.14.0 Aborts with -vga qxl

2011-05-04 Thread Serge Hallyn
@Boris

Thanks for this work.  Would you be interested in pursuing the process
to push these packages (celt051, the spice packages, and qemu-kvm-spice
based on your new package) into the Ubuntu archive?  The process is
described at https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages.

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

Title:
  qemu-kvm-0.14.0 Aborts with -vga qxl

Status in QEMU:
  Confirmed
Status in “libvirt” package in Ubuntu:
  Triaged
Status in “qemu-kvm” package in Ubuntu:
  Fix Released

Bug description:
  Host CPU is Core i7 Q820.  KVM is from 2.6.35-gentoo-r5 kernel (x86_64).
  Host has spice-0.7.2 and spice-protocol-0.7.0.
  Guest is Windows XP SP3 with qxl driver 0.6.1, virtio-serial 1.1.6 and 
vdagent 0.6.3.

  qemu-kvm is started like so:
  qemu-system-x86_64 -cpu host -enable-kvm -pidfile /home/rick/qemu/hds/wxp.pid 
-drive 
file=/home/rick/qemu/hds/wxp.raw,if=virtio,media=disk,aio=native,snapshot=on -m 
768 -name WinXP -net nic,model=virtio -net user -localtime -usb -vga qxl 
-device virtio-serial -chardev spicevmc,name=vdagent,id=vdagent -device 
virtserialport,chardev=vdagent,name=com.redhat.spice.0 -spice 
port=1234,disable-ticketing -monitor stdio
  and crashes with:
  qemu-system-x86_64: /home/rick/qemu/src/qemu-kvm-0.14.0/qemu-kvm.c:1724: 
kvm_mutex_unlock: Assertion `!cpu_single_env' failed.
  Aborted

  If I use -no-kvm, it works fine.  If I use -vga std, it works fine.
  -enable-kvm and -vga qxl crashes.



Re: [Qemu-devel] [Qemu-trivial] [PATCH 01/18] Fix typos in comments (dependancy -> dependency)

2011-05-04 Thread Stefan Hajnoczi
On Tue, May 3, 2011 at 9:25 PM, Stefan Weil  wrote:
> Am 28.04.2011 17:20, schrieb Stefan Weil:
>>
>> Signed-off-by: Stefan Weil 
>> ---
>> Changelog | 2 +-
>> Makefile.objs | 2 +-
>> 2 files changed, 2 insertions(+), 2 deletions(-)
>>
>
> There were no replies to the patch series up to now.

Sorry, I have been away on holiday and am still catching back up.
Let's take them as they are.

Stefan



[Qemu-devel] A Question

2011-05-04 Thread Zhenkai Zhang
Hi, guys,

I want to emulate some code for ARM7TDMI. Does Qemu support this ARM type?

Thank you

Zhenkai



Re: [Qemu-devel] [RFC 03/28] target-xtensa: implement disas_xtensa_insn

2011-05-04 Thread Richard Henderson
On 05/03/2011 05:59 PM, Max Filippov wrote:
> +static void gen_jump(DisasContext *dc, TCGv dest)
> +{
> +tcg_gen_mov_i32(cpu_pc, dest);
> +if (dc->singlestep_enabled) {
> +gen_exception(EXCP_DEBUG);
> +}
> +tcg_gen_exit_tb(0);
> +dc->is_jmp = DISAS_UPDATE;

You're generating useless instructions here.  The exception
is a noreturn function.  It performs a longjmp to back out
of the cpu loop.

Thus the exit_tb should be in an else here.

> +invalid_opcode:
> +printf("INVALID(pc = %08x): %s:%d\n", dc->pc, __FILE__, __LINE__);

Don't printf.  Use the logging functions properly.


r~



[Qemu-devel] [PATCH 01/14] usb-linux: introduce a usb_linux_alt_setting function

2011-05-04 Thread Gerd Hoffmann
From: Hans de Goede 

The next patch in this series introduces multiple ways to get the
alt setting dependent upon usb_fs_type, it is cleaner to put this
into its own function.

Note that this patch also changes the assumed alt setting in case
of an error getting the alt setting to be 0 (a sane default) rather
then the interface numberwhich makes no sense.

Signed-off-by: Hans de Goede 
Signed-off-by: Gerd Hoffmann 
---
 usb-linux.c |   40 +---
 1 files changed, 25 insertions(+), 15 deletions(-)

diff --git a/usb-linux.c b/usb-linux.c
index 1f33c2c..353e1b1 100644
--- a/usb-linux.c
+++ b/usb-linux.c
@@ -823,13 +823,35 @@ usbdevfs:
 return configuration;
 }
 
+static uint8_t usb_linux_get_alt_setting(USBHostDevice *s,
+uint8_t configuration, uint8_t interface)
+{
+uint8_t alt_setting;
+struct usb_ctrltransfer ct;
+int ret;
+
+ct.bRequestType = USB_DIR_IN | USB_RECIP_INTERFACE;
+ct.bRequest = USB_REQ_GET_INTERFACE;
+ct.wValue = 0;
+ct.wIndex = interface;
+ct.wLength = 1;
+ct.data = &alt_setting;
+ct.timeout = 50;
+ret = ioctl(s->fd, USBDEVFS_CONTROL, &ct);
+if (ret < 0) {
+/* Assume alt 0 on error */
+return 0;
+}
+
+return alt_setting;
+}
+
 /* returns 1 on problem encountered or 0 for success */
 static int usb_linux_update_endp_table(USBHostDevice *s)
 {
 uint8_t *descriptors;
 uint8_t devep, type, configuration, alt_interface;
-struct usb_ctrltransfer ct;
-int interface, ret, length, i;
+int interface, length, i;
 
 i = usb_linux_get_configuration(s);
 if (i < 0)
@@ -858,19 +880,7 @@ static int usb_linux_update_endp_table(USBHostDevice *s)
 }
 
 interface = descriptors[i + 2];
-
-ct.bRequestType = USB_DIR_IN | USB_RECIP_INTERFACE;
-ct.bRequest = USB_REQ_GET_INTERFACE;
-ct.wValue = 0;
-ct.wIndex = interface;
-ct.wLength = 1;
-ct.data = &alt_interface;
-ct.timeout = 50;
-
-ret = ioctl(s->fd, USBDEVFS_CONTROL, &ct);
-if (ret < 0) {
-alt_interface = interface;
-}
+alt_interface = usb_linux_get_alt_setting(s, configuration, interface);
 
 /* the current interface descriptor is the active interface
  * and has endpoints */
-- 
1.7.1




[Qemu-devel] [PULL] usb patch queue

2011-05-04 Thread Gerd Hoffmann
  Hi,

The USB patch queue is back!  I'm still busy catching up with the
backlog, I know I didn't pick up everything from the list yet.  If in
doubt it doesn't hurt to resend usb related patches, with me being
Cc'ed.

This pull brings old stuff, most of the patches are several months old
already.  Finally the usb-host fixes from Hans are queued up for merge.
Some async packet handling cleanups are in there to.  Oh, and one more
bugfix for the usb mass storage device.

please pull,
  Gerd

The following changes since commit d2d979c628e4b2c4a3cb71a31841875795c79043:

  NBD: Avoid leaking a couple of strings when the NBD device is closed 
(2011-05-03 11:29:21 +0200)

are available in the git repository at:
  git://git.kraxel.org/qemu usb.7.pull

Gerd Hoffmann (6):
  uhci: switch to QTAILQ
  uhci: keep uhci state pointer in async packet struct.
  ohci: get ohci state via container_of()
  musb: get musb state via container_of()
  usb: move complete callback to port ops
  usb: mass storage fix

Hans de Goede (8):
  usb-linux: introduce a usb_linux_alt_setting function
  usb-linux: Get the alt. setting from sysfs rather then asking the dev
  usb-linux: Add support for buffering iso usb packets
  usb-linux: Refuse packets for endpoints which are not in the usb 
descriptor
  usb-linux: Refuse iso packets when max packet size is 0 (alt setting 0)
  usb-linux: We only need to keep track of 15 endpoints
  usb-linux: Add support for buffering iso out usb packets
  usb: control buffer fixes

 hw/usb-hub.c  |   14 ++
 hw/usb-msd.c  |5 +-
 hw/usb-musb.c |   75 ++-
 hw/usb-ohci.c |9 +-
 hw/usb-uhci.c |   82 
 hw/usb.c  |6 +
 hw/usb.h  |9 +-
 usb-linux.c   |  394 ++---
 8 files changed, 445 insertions(+), 149 deletions(-)



[Qemu-devel] [PATCH 02/14] usb-linux: Get the alt. setting from sysfs rather then asking the dev

2011-05-04 Thread Gerd Hoffmann
From: Hans de Goede 

At least one device I have lies when receiving a USB_REQ_GET_INTERFACE,
always returning 0 even if the alternate setting is different. This is
likely caused because in practice this control message is never used as
the operating system's usb stack knows which alternate setting it has
told the device to get into, and thus this ctrl message does not get
tested by device manufacturers.

When usb_fs_type == USB_FS_SYS, the active alt. setting can be read directly
from sysfs, which allows using this device through qemu's usb redirection.
More in general it seems a good idea to not send needless control msg's to
devices, esp. as the code in question is called every time a set_interface
is done. Which happens multiple times during virtual machine startup, and
when device drivers are activating the usb device.

Signed-off-by: Hans de Goede 
Signed-off-by: Gerd Hoffmann 
---
 usb-linux.c |   18 ++
 1 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/usb-linux.c b/usb-linux.c
index 353e1b1..f4601e6 100644
--- a/usb-linux.c
+++ b/usb-linux.c
@@ -830,6 +830,24 @@ static uint8_t usb_linux_get_alt_setting(USBHostDevice *s,
 struct usb_ctrltransfer ct;
 int ret;
 
+if (usb_fs_type == USB_FS_SYS) {
+char device_name[64], line[1024];
+int alt_setting;
+
+sprintf(device_name, "%d-%d:%d.%d", s->bus_num, s->devpath,
+(int)configuration, (int)interface);
+
+if (!usb_host_read_file(line, sizeof(line), "bAlternateSetting",
+device_name)) {
+goto usbdevfs;
+}
+if (sscanf(line, "%d", &alt_setting) != 1) {
+goto usbdevfs;
+}
+return alt_setting;
+}
+
+usbdevfs:
 ct.bRequestType = USB_DIR_IN | USB_RECIP_INTERFACE;
 ct.bRequest = USB_REQ_GET_INTERFACE;
 ct.wValue = 0;
-- 
1.7.1




[Qemu-devel] [PATCH 03/14] usb-linux: Add support for buffering iso usb packets

2011-05-04 Thread Gerd Hoffmann
From: Hans de Goede 

Currently we are submitting iso packets to the host one at a time, as we
receive them from the emulated host controller. This has 2 problems:
1) If we were fast enough to submit every packet in time for the next host host
controller usb frame, we would be generating 1000 hardware interrupts per
second on the host
2) We are not fast enough to submit every packet in time for the next host host
controller usb frame, causing us to not submit iso urbs in some usb frames
which causes devices with an endpoint with an interval of 1 ms (so every
frame) to loose data. This causes for example ubs-1.1 webcams to not work
properly (usb-2.0 is not supported at all atm).

This patch fixes both problems by changing the iso packet pass through handling
to buffer packets. This version only does so for iso input packets (webcams,
audio in) I'm working on a second patch extending this to iso output packets
(audio out).

This patch makes use of the linux batching of iso packets in one urb.
When an iso in packet gets received from the emulated host controller,
it immediately submits 3 urbs with 32 iso in packets each. This causes
the host to only get an hw interrupt every 32 packets dropping the
interrupt rate to 32 interrupts per second and gives it a queue of urbs
to work from once the first 32 iso in packets have been received to make sure
no packets are dropped.

Besides submitting a whole bunch or urbs as soon as the first urb is
received, effectively creating a buffer inside the kernel, this patch also
gets rid of the asynchroneous completion for iso in urbs. Instead they are
only marked as complete in the fd write callback (which usbfs uses to signal
complete urbs). These complete packets then get consumed by returning them
synchroneously to the emulated host controller when it submits an iso in
packet for the ep in question. When no complete packets are ready (which
happens when the stream is starting) a 0 length packet gets returned to
the emulated host controller.

With this patch I've several usb-1.1 webcams working well with usb pass
through, where as without this patch none of them work.

Signed-off-by: Hans de Goede 
Signed-off-by: Gerd Hoffmann 
---
 usb-linux.c |  243 ++
 1 files changed, 226 insertions(+), 17 deletions(-)

diff --git a/usb-linux.c b/usb-linux.c
index f4601e6..a68603d 100644
--- a/usb-linux.c
+++ b/usb-linux.c
@@ -92,9 +92,17 @@ static char *usb_host_device_path;
 static int usb_fs_type;
 
 /* endpoint association data */
+#define ISO_FRAME_DESC_PER_URB 32
+#define ISO_URB_COUNT 3
+
+typedef struct AsyncURB AsyncURB;
+
 struct endp_data {
 uint8_t type;
 uint8_t halted;
+AsyncURB *iso_urb;
+int iso_urb_idx;
+int max_packet_size;
 };
 
 enum {
@@ -175,19 +183,48 @@ static void set_halt(USBHostDevice *s, int ep)
 s->endp_table[ep - 1].halted = 1;
 }
 
+static void set_iso_urb(USBHostDevice *s, int ep, AsyncURB *iso_urb)
+{
+s->endp_table[ep - 1].iso_urb = iso_urb;
+}
+
+static AsyncURB *get_iso_urb(USBHostDevice *s, int ep)
+{
+return s->endp_table[ep - 1].iso_urb;
+}
+
+static void set_iso_urb_idx(USBHostDevice *s, int ep, int i)
+{
+s->endp_table[ep - 1].iso_urb_idx = i;
+}
+
+static int get_iso_urb_idx(USBHostDevice *s, int ep)
+{
+return s->endp_table[ep - 1].iso_urb_idx;
+}
+
+static int get_max_packet_size(USBHostDevice *s, int ep)
+{
+return s->endp_table[ep - 1].max_packet_size;
+}
+
 /*
  * Async URB state.
- * We always allocate one isoc descriptor even for bulk transfers
+ * We always allocate iso packet descriptors even for bulk transfers
  * to simplify allocation and casts.
  */
-typedef struct AsyncURB
+struct AsyncURB
 {
 struct usbdevfs_urb urb;
-struct usbdevfs_iso_packet_desc isocpd;
+struct usbdevfs_iso_packet_desc isocpd[ISO_FRAME_DESC_PER_URB];
 
+/* For regular async urbs */
 USBPacket *packet;
 USBHostDevice *hdev;
-} AsyncURB;
+
+/* For buffered iso handling */
+int iso_frame_idx; /* -1 means in flight */
+};
 
 static AsyncURB *async_alloc(void)
 {
@@ -244,11 +281,21 @@ static void async_complete(void *opaque)
 return;
 }
 
-p = aurb->packet;
-
 DPRINTF("husb: async completed. aurb %p status %d alen %d\n",
 aurb, aurb->urb.status, aurb->urb.actual_length);
 
+/* If this is a buffered iso urb mark it as complete and don't do
+   anything else (it is handled further in usb_host_handle_iso_data) */
+if (aurb->iso_frame_idx == -1) {
+if (aurb->urb.status == -EPIPE) {
+set_halt(s, aurb->urb.endpoint & 0xf);
+}
+aurb->iso_frame_idx = 0;
+continue;
+}
+
+p = aurb->packet;
+
 if (p) {
 switch (aurb->urb.status) {
 case 0:
@@ -415,34 +462,181 @@ static void usb_host_handle_destroy(USBDevice *dev)
 
 static int usb_linux_update_endp_table(USB

[Qemu-devel] [PATCH 07/14] usb-linux: Add support for buffering iso out usb packets

2011-05-04 Thread Gerd Hoffmann
From: Hans de Goede 

Extend the iso buffering code to also buffer iso out packets, this
fixes for example using usb speakers with usb redirection.

Signed-off-by: Hans de Goede 
Signed-off-by: Gerd Hoffmann 
---
 usb-linux.c |  152 +++
 1 files changed, 101 insertions(+), 51 deletions(-)

diff --git a/usb-linux.c b/usb-linux.c
index 4498b16..730eac2 100644
--- a/usb-linux.c
+++ b/usb-linux.c
@@ -101,8 +101,10 @@ typedef struct AsyncURB AsyncURB;
 struct endp_data {
 uint8_t type;
 uint8_t halted;
+uint8_t iso_started;
 AsyncURB *iso_urb;
 int iso_urb_idx;
+int iso_buffer_used;
 int max_packet_size;
 };
 
@@ -189,6 +191,21 @@ static void set_halt(USBHostDevice *s, int ep)
 s->endp_table[ep - 1].halted = 1;
 }
 
+static int is_iso_started(USBHostDevice *s, int ep)
+{
+return s->endp_table[ep - 1].iso_started;
+}
+
+static void clear_iso_started(USBHostDevice *s, int ep)
+{
+s->endp_table[ep - 1].iso_started = 0;
+}
+
+static void set_iso_started(USBHostDevice *s, int ep)
+{
+s->endp_table[ep - 1].iso_started = 1;
+}
+
 static void set_iso_urb(USBHostDevice *s, int ep, AsyncURB *iso_urb)
 {
 s->endp_table[ep - 1].iso_urb = iso_urb;
@@ -209,6 +226,16 @@ static int get_iso_urb_idx(USBHostDevice *s, int ep)
 return s->endp_table[ep - 1].iso_urb_idx;
 }
 
+static void set_iso_buffer_used(USBHostDevice *s, int ep, int i)
+{
+s->endp_table[ep - 1].iso_buffer_used = i;
+}
+
+static int get_iso_buffer_used(USBHostDevice *s, int ep)
+{
+return s->endp_table[ep - 1].iso_buffer_used;
+}
+
 static int get_max_packet_size(USBHostDevice *s, int ep)
 {
 return s->endp_table[ep - 1].max_packet_size;
@@ -534,6 +561,8 @@ static void usb_host_stop_n_free_iso(USBHostDevice *s, 
uint8_t ep)
 else
 printf("husb: leaking iso urbs because of discard failure\n");
 set_iso_urb(s, ep, NULL);
+set_iso_urb_idx(s, ep, 0);
+clear_iso_started(s, ep);
 }
 
 static int urb_status_to_usb_ret(int status)
@@ -546,10 +575,10 @@ static int urb_status_to_usb_ret(int status)
 }
 }
 
-static int usb_host_handle_iso_data(USBHostDevice *s, USBPacket *p)
+static int usb_host_handle_iso_data(USBHostDevice *s, USBPacket *p, int in)
 {
 AsyncURB *aurb;
-int i, j, ret, max_packet_size, len = 0;
+int i, j, ret, max_packet_size, offset, len = 0;
 
 max_packet_size = get_max_packet_size(s, p->devep);
 if (max_packet_size == 0)
@@ -557,57 +586,88 @@ static int usb_host_handle_iso_data(USBHostDevice *s, 
USBPacket *p)
 
 aurb = get_iso_urb(s, p->devep);
 if (!aurb) {
-aurb = usb_host_alloc_iso(s, p->devep, 1);
+aurb = usb_host_alloc_iso(s, p->devep, in);
 }
 
 i = get_iso_urb_idx(s, p->devep);
 j = aurb[i].iso_frame_idx;
 if (j >= 0 && j < ISO_FRAME_DESC_PER_URB) {
-/* Check urb status  */
-if (aurb[i].urb.status) {
-len = urb_status_to_usb_ret(aurb[i].urb.status);
-/* Move to the next urb */
-aurb[i].iso_frame_idx = ISO_FRAME_DESC_PER_URB - 1;
-/* Check frame status */
-} else if (aurb[i].urb.iso_frame_desc[j].status) {
-len = urb_status_to_usb_ret(aurb[i].urb.iso_frame_desc[j].status);
-/* Check the frame fits */
-} else if (aurb[i].urb.iso_frame_desc[j].actual_length > p->len) {
-printf("husb: error received isoc data is larger then packet\n");
-len = USB_RET_NAK;
-/* All good copy data over */
+if (in) {
+/* Check urb status  */
+if (aurb[i].urb.status) {
+len = urb_status_to_usb_ret(aurb[i].urb.status);
+/* Move to the next urb */
+aurb[i].iso_frame_idx = ISO_FRAME_DESC_PER_URB - 1;
+/* Check frame status */
+} else if (aurb[i].urb.iso_frame_desc[j].status) {
+len = urb_status_to_usb_ret(
+aurb[i].urb.iso_frame_desc[j].status);
+/* Check the frame fits */
+} else if (aurb[i].urb.iso_frame_desc[j].actual_length > p->len) {
+printf("husb: received iso data is larger then packet\n");
+len = USB_RET_NAK;
+/* All good copy data over */
+} else {
+len = aurb[i].urb.iso_frame_desc[j].actual_length;
+memcpy(p->data,
+   aurb[i].urb.buffer +
+   j * aurb[i].urb.iso_frame_desc[0].length,
+   len);
+}
 } else {
-len = aurb[i].urb.iso_frame_desc[j].actual_length;
-memcpy(p->data,
-   aurb[i].urb.buffer +
-   j * aurb[i].urb.iso_frame_desc[0].length,
-   len);
+len = p->len;
+offset = (j == 0) ? 0 : get_iso_buffer_used(s, p->devep);
+
+/* Check the frame fits */
+if (l

[Qemu-devel] [PATCH 04/14] usb-linux: Refuse packets for endpoints which are not in the usb descriptor

2011-05-04 Thread Gerd Hoffmann
From: Hans de Goede 

If an endpoint is not in the usb descriptor we've no idea what kind of
endpoint it is and thus how to handle it, refuse packages in this case.

Signed-off-by: Hans de Goede 
Signed-off-by: Gerd Hoffmann 
---
 usb-linux.c |   13 +
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/usb-linux.c b/usb-linux.c
index a68603d..6aef7a5 100644
--- a/usb-linux.c
+++ b/usb-linux.c
@@ -94,6 +94,7 @@ static int usb_fs_type;
 /* endpoint association data */
 #define ISO_FRAME_DESC_PER_URB 32
 #define ISO_URB_COUNT 3
+#define INVALID_EP_TYPE 255
 
 typedef struct AsyncURB AsyncURB;
 
@@ -168,6 +169,11 @@ static int is_isoc(USBHostDevice *s, int ep)
 return s->endp_table[ep - 1].type == USBDEVFS_URB_TYPE_ISO;
 }
 
+static int is_valid(USBHostDevice *s, int ep)
+{
+return s->endp_table[ep - 1].type != INVALID_EP_TYPE;
+}
+
 static int is_halted(USBHostDevice *s, int ep)
 {
 return s->endp_table[ep - 1].halted;
@@ -611,6 +617,10 @@ static int usb_host_handle_data(USBHostDevice *s, 
USBPacket *p)
 int ret;
 uint8_t ep;
 
+if (!is_valid(s, p->devep)) {
+return USB_RET_NAK;
+}
+
 if (p->pid == USB_TOKEN_IN) {
 ep = p->devep | 0x80;
 } else {
@@ -1071,6 +1081,9 @@ static int usb_linux_update_endp_table(USBHostDevice *s)
 uint8_t devep, type, configuration, alt_interface;
 int interface, length, i;
 
+for (i = 0; i < MAX_ENDPOINTS; i++)
+s->endp_table[i].type = INVALID_EP_TYPE;
+
 i = usb_linux_get_configuration(s);
 if (i < 0)
 return 1;
-- 
1.7.1




[Qemu-devel] [PATCH 11/14] ohci: get ohci state via container_of()

2011-05-04 Thread Gerd Hoffmann
Signed-off-by: Gerd Hoffmann 
---
 hw/usb-ohci.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/hw/usb-ohci.c b/hw/usb-ohci.c
index 0ad4f55..7678cdb 100644
--- a/hw/usb-ohci.c
+++ b/hw/usb-ohci.c
@@ -577,7 +577,7 @@ static void ohci_process_lists(OHCIState *ohci, int 
completion);
 
 static void ohci_async_complete_packet(USBPacket *packet, void *opaque)
 {
-OHCIState *ohci = opaque;
+OHCIState *ohci = container_of(packet, OHCIState, usb_packet);
 #ifdef DEBUG_PACKET
 DPRINTF("Async packet complete\n");
 #endif
-- 
1.7.1




[Qemu-devel] [PATCH 05/14] usb-linux: Refuse iso packets when max packet size is 0 (alt setting 0)

2011-05-04 Thread Gerd Hoffmann
From: Hans de Goede 

Refuse iso usb packets when then max packet size for the endpoint is 0,
this avoids an abort in usb_host_alloc_iso() caused by trying to qemu_malloc
a 0 bytes large buffer.

Signed-off-by: Gerd Hoffmann 
---
 usb-linux.c |6 +-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/usb-linux.c b/usb-linux.c
index 6aef7a5..4c42fe1 100644
--- a/usb-linux.c
+++ b/usb-linux.c
@@ -549,7 +549,11 @@ static int urb_status_to_usb_ret(int status)
 static int usb_host_handle_iso_data(USBHostDevice *s, USBPacket *p)
 {
 AsyncURB *aurb;
-int i, j, ret, len = 0;
+int i, j, ret, max_packet_size, len = 0;
+
+max_packet_size = get_max_packet_size(s, p->devep);
+if (max_packet_size == 0)
+return USB_RET_NAK;
 
 aurb = get_iso_urb(s, p->devep);
 if (!aurb) {
-- 
1.7.1




[Qemu-devel] [PATCH 10/14] uhci: keep uhci state pointer in async packet struct.

2011-05-04 Thread Gerd Hoffmann
Signed-off-by: Gerd Hoffmann 
---
 hw/usb-uhci.c |   12 
 1 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/hw/usb-uhci.c b/hw/usb-uhci.c
index 2de0cf2..2b63b3f 100644
--- a/hw/usb-uhci.c
+++ b/hw/usb-uhci.c
@@ -106,6 +106,8 @@ static void dump_data(const uint8_t *data, int len)
 static void dump_data(const uint8_t *data, int len) {}
 #endif
 
+typedef struct UHCIState UHCIState;
+
 /* 
  * Pending async transaction.
  * 'packet' must be the first field because completion
@@ -113,6 +115,7 @@ static void dump_data(const uint8_t *data, int len) {}
  */
 typedef struct UHCIAsync {
 USBPacket packet;
+UHCIState *uhci;
 QTAILQ_ENTRY(UHCIAsync) next;
 uint32_t  td;
 uint32_t  token;
@@ -127,7 +130,7 @@ typedef struct UHCIPort {
 uint16_t ctrl;
 } UHCIPort;
 
-typedef struct UHCIState {
+struct UHCIState {
 PCIDevice dev;
 USBBus bus;
 uint16_t cmd; /* cmd register */
@@ -147,7 +150,7 @@ typedef struct UHCIState {
 /* Active packets */
 QTAILQ_HEAD(,UHCIAsync) async_pending;
 uint8_t num_ports_vmstate;
-} UHCIState;
+};
 
 typedef struct UHCI_TD {
 uint32_t link;
@@ -166,6 +169,7 @@ static UHCIAsync *uhci_async_alloc(UHCIState *s)
 UHCIAsync *async = qemu_malloc(sizeof(UHCIAsync));
 
 memset(&async->packet, 0, sizeof(async->packet));
+async->uhci  = s;
 async->valid = 0;
 async->td= 0;
 async->token = 0;
@@ -830,8 +834,8 @@ done:
 
 static void uhci_async_complete(USBPacket *packet, void *opaque)
 {
-UHCIState *s = opaque;
-UHCIAsync *async = (UHCIAsync *) packet;
+UHCIAsync *async = container_of(packet, UHCIAsync, packet);
+UHCIState *s = async->uhci;
 
 DPRINTF("uhci: async complete. td 0x%x token 0x%x\n", async->td, 
async->token);
 
-- 
1.7.1




[Qemu-devel] [PATCH 06/14] usb-linux: We only need to keep track of 15 endpoints

2011-05-04 Thread Gerd Hoffmann
From: Hans de Goede 

Currently we reserve room for endpoint data for 16 endpoints, but given
that we only use endpoint data for endpoints 1-15, and always index the
array with the endpoint-number - 1, 15 is enough.

Signed-off-by: Hans de Goede 
Signed-off-by: Gerd Hoffmann 
---
 usb-linux.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/usb-linux.c b/usb-linux.c
index 4c42fe1..4498b16 100644
--- a/usb-linux.c
+++ b/usb-linux.c
@@ -78,7 +78,7 @@ typedef int USBScanFunc(void *opaque, int bus_num, int addr, 
int devpath,
 
 #define USBPROCBUS_PATH "/proc/bus/usb"
 #define PRODUCT_NAME_SZ 32
-#define MAX_ENDPOINTS 16
+#define MAX_ENDPOINTS 15
 #define USBDEVBUS_PATH "/dev/bus/usb"
 #define USBSYSBUS_PATH "/sys/bus/usb"
 
@@ -725,7 +725,7 @@ static int usb_host_set_interface(USBHostDevice *s, int 
iface, int alt)
 struct usbdevfs_setinterface si;
 int i, ret;
 
-for (i = 1; i < MAX_ENDPOINTS; i++) {
+for (i = 1; i <= MAX_ENDPOINTS; i++) {
 if (is_isoc(s, i)) {
 usb_host_stop_n_free_iso(s, i);
 }
@@ -1276,7 +1276,7 @@ static int usb_host_close(USBHostDevice *dev)
 
 qemu_set_fd_handler(dev->fd, NULL, NULL, NULL);
 dev->closing = 1;
-for (i = 1; i < MAX_ENDPOINTS; i++) {
+for (i = 1; i <= MAX_ENDPOINTS; i++) {
 if (is_isoc(dev, i)) {
 usb_host_stop_n_free_iso(dev, i);
 }
-- 
1.7.1




[Qemu-devel] [PATCH 09/14] uhci: switch to QTAILQ

2011-05-04 Thread Gerd Hoffmann

Signed-off-by: Gerd Hoffmann 
---
 hw/usb-uhci.c |   63 +---
 1 files changed, 15 insertions(+), 48 deletions(-)

diff --git a/hw/usb-uhci.c b/hw/usb-uhci.c
index 346db3e..2de0cf2 100644
--- a/hw/usb-uhci.c
+++ b/hw/usb-uhci.c
@@ -113,7 +113,7 @@ static void dump_data(const uint8_t *data, int len) {}
  */
 typedef struct UHCIAsync {
 USBPacket packet;
-struct UHCIAsync *next;
+QTAILQ_ENTRY(UHCIAsync) next;
 uint32_t  td;
 uint32_t  token;
 int8_tvalid;
@@ -145,8 +145,7 @@ typedef struct UHCIState {
 uint32_t pending_int_mask;
 
 /* Active packets */
-UHCIAsync *async_pending;
-UHCIAsync *async_pool;
+QTAILQ_HEAD(,UHCIAsync) async_pending;
 uint8_t num_ports_vmstate;
 } UHCIState;
 
@@ -172,7 +171,6 @@ static UHCIAsync *uhci_async_alloc(UHCIState *s)
 async->token = 0;
 async->done  = 0;
 async->isoc  = 0;
-async->next  = NULL;
 
 return async;
 }
@@ -184,24 +182,12 @@ static void uhci_async_free(UHCIState *s, UHCIAsync 
*async)
 
 static void uhci_async_link(UHCIState *s, UHCIAsync *async)
 {
-async->next = s->async_pending;
-s->async_pending = async;
+QTAILQ_INSERT_HEAD(&s->async_pending, async, next);
 }
 
 static void uhci_async_unlink(UHCIState *s, UHCIAsync *async)
 {
-UHCIAsync *curr = s->async_pending;
-UHCIAsync **prev = &s->async_pending;
-
-while (curr) {
-   if (curr == async) {
-*prev = curr->next;
-return;
-}
-
-prev = &curr->next;
-curr = curr->next;
-}
+QTAILQ_REMOVE(&s->async_pending, async, next);
 }
 
 static void uhci_async_cancel(UHCIState *s, UHCIAsync *async)
@@ -220,11 +206,10 @@ static void uhci_async_cancel(UHCIState *s, UHCIAsync 
*async)
  */
 static UHCIAsync *uhci_async_validate_begin(UHCIState *s)
 {
-UHCIAsync *async = s->async_pending;
+UHCIAsync *async;
 
-while (async) {
+QTAILQ_FOREACH(async, &s->async_pending, next) {
 async->valid--;
-async = async->next;
 }
 return NULL;
 }
@@ -234,47 +219,30 @@ static UHCIAsync *uhci_async_validate_begin(UHCIState *s)
  */
 static void uhci_async_validate_end(UHCIState *s)
 {
-UHCIAsync *curr = s->async_pending;
-UHCIAsync **prev = &s->async_pending;
-UHCIAsync *next;
+UHCIAsync *curr, *n;
 
-while (curr) {
+QTAILQ_FOREACH_SAFE(curr, &s->async_pending, next, n) {
 if (curr->valid > 0) {
-prev = &curr->next;
-curr = curr->next;
 continue;
 }
-
-next = curr->next;
-
-/* Unlink */
-*prev = next;
-
+uhci_async_unlink(s, curr);
 uhci_async_cancel(s, curr);
-
-curr = next;
 }
 }
 
 static void uhci_async_cancel_all(UHCIState *s)
 {
-UHCIAsync *curr = s->async_pending;
-UHCIAsync *next;
-
-while (curr) {
-next = curr->next;
+UHCIAsync *curr, *n;
 
+QTAILQ_FOREACH_SAFE(curr, &s->async_pending, next, n) {
+uhci_async_unlink(s, curr);
 uhci_async_cancel(s, curr);
-
-curr = next;
 }
-
-s->async_pending = NULL;
 }
 
 static UHCIAsync *uhci_async_find_td(UHCIState *s, uint32_t addr, uint32_t 
token)
 {
-UHCIAsync *async = s->async_pending;
+UHCIAsync *async;
 UHCIAsync *match = NULL;
 int count = 0;
 
@@ -291,7 +259,7 @@ static UHCIAsync *uhci_async_find_td(UHCIState *s, uint32_t 
addr, uint32_t token
  * If we ever do we'd want to optimize this algorithm.
  */
 
-while (async) {
+QTAILQ_FOREACH(async, &s->async_pending, next) {
 if (async->token == token) {
 /* Good match */
 match = async;
@@ -301,8 +269,6 @@ static UHCIAsync *uhci_async_find_td(UHCIState *s, uint32_t 
addr, uint32_t token
 break;
 }
 }
-
-async = async->next;
 count++;
 }
 
@@ -1137,6 +1103,7 @@ static int usb_uhci_common_initfn(UHCIState *s)
 s->expire_time = qemu_get_clock_ns(vm_clock) +
 (get_ticks_per_sec() / FRAME_TIMER_FREQ);
 s->num_ports_vmstate = NB_PORTS;
+QTAILQ_INIT(&s->async_pending);
 
 qemu_register_reset(uhci_reset, s);
 
-- 
1.7.1




[Qemu-devel] [PATCH 12/14] musb: get musb state via container_of()

2011-05-04 Thread Gerd Hoffmann

Signed-off-by: Gerd Hoffmann 
---
 hw/usb-musb.c |   54 ++
 1 files changed, 34 insertions(+), 20 deletions(-)

diff --git a/hw/usb-musb.c b/hw/usb-musb.c
index 15bc549..30148e7 100644
--- a/hw/usb-musb.c
+++ b/hw/usb-musb.c
@@ -267,7 +267,16 @@ static USBPortOps musb_port_ops = {
 .detach = musb_detach,
 };
 
-typedef struct {
+typedef struct MUSBPacket MUSBPacket;
+typedef struct MUSBEndPoint MUSBEndPoint;
+
+struct MUSBPacket {
+USBPacket p;
+MUSBEndPoint *ep;
+int dir;
+};
+
+struct MUSBEndPoint {
 uint16_t faddr[2];
 uint8_t haddr[2];
 uint8_t hport[2];
@@ -284,7 +293,7 @@ typedef struct {
 int fifolen[2];
 int fifostart[2];
 int fifoaddr[2];
-USBPacket packey[2];
+MUSBPacket packey[2];
 int status[2];
 int ext_size[2];
 
@@ -294,7 +303,7 @@ typedef struct {
 MUSBState *musb;
 USBCallback *delayed_cb[2];
 QEMUTimer *intv_timer[2];
-} MUSBEndPoint;
+};
 
 struct MUSBState {
 qemu_irq *irqs;
@@ -321,7 +330,9 @@ struct MUSBState {
 /* Duplicating the world since 2008!...  probably we should have 32
  * logical, single endpoints instead.  */
 MUSBEndPoint ep[16];
-} *musb_init(qemu_irq *irqs)
+};
+
+struct MUSBState *musb_init(qemu_irq *irqs)
 {
 MUSBState *s = qemu_mallocz(sizeof(*s));
 int i;
@@ -488,14 +499,14 @@ static inline void musb_cb_tick0(void *opaque)
 {
 MUSBEndPoint *ep = (MUSBEndPoint *) opaque;
 
-ep->delayed_cb[0](&ep->packey[0], opaque);
+ep->delayed_cb[0](&ep->packey[0].p, opaque);
 }
 
 static inline void musb_cb_tick1(void *opaque)
 {
 MUSBEndPoint *ep = (MUSBEndPoint *) opaque;
 
-ep->delayed_cb[1](&ep->packey[1], opaque);
+ep->delayed_cb[1](&ep->packey[1].p, opaque);
 }
 
 #define musb_cb_tick   (dir ? musb_cb_tick1 : musb_cb_tick0)
@@ -587,17 +598,19 @@ static inline void musb_packet(MUSBState *s, MUSBEndPoint 
*ep,
 ep->delayed_cb[dir] = cb;
 cb = dir ? musb_schedule1_cb : musb_schedule0_cb;
 
-ep->packey[dir].pid = pid;
+ep->packey[dir].p.pid = pid;
 /* A wild guess on the FADDR semantics... */
-ep->packey[dir].devaddr = ep->faddr[idx];
-ep->packey[dir].devep = ep->type[idx] & 0xf;
-ep->packey[dir].data = (void *) ep->buf[idx];
-ep->packey[dir].len = len;
-ep->packey[dir].complete_cb = cb;
-ep->packey[dir].complete_opaque = ep;
+ep->packey[dir].p.devaddr = ep->faddr[idx];
+ep->packey[dir].p.devep = ep->type[idx] & 0xf;
+ep->packey[dir].p.data = (void *) ep->buf[idx];
+ep->packey[dir].p.len = len;
+ep->packey[dir].p.complete_cb = cb;
+ep->packey[dir].p.complete_opaque = ep;
+ep->packey[dir].ep = ep;
+ep->packey[dir].dir = dir;
 
 if (s->port.dev)
-ret = s->port.dev->info->handle_packet(s->port.dev, &ep->packey[dir]);
+ret = s->port.dev->info->handle_packet(s->port.dev, 
&ep->packey[dir].p);
 else
 ret = USB_RET_NODEV;
 
@@ -607,7 +620,7 @@ static inline void musb_packet(MUSBState *s, MUSBEndPoint 
*ep,
 }
 
 ep->status[dir] = ret;
-usb_packet_complete(&ep->packey[dir]);
+usb_packet_complete(&ep->packey[dir].p);
 }
 
 static void musb_tx_packet_complete(USBPacket *packey, void *opaque)
@@ -821,14 +834,14 @@ static void musb_rx_req(MUSBState *s, int epnum)
 
 /* If we already have a packet, which didn't fit into the
  * 64 bytes of the FIFO, only move the FIFO start and return. (Obsolete) */
-if (ep->packey[1].pid == USB_TOKEN_IN && ep->status[1] >= 0 &&
+if (ep->packey[1].p.pid == USB_TOKEN_IN && ep->status[1] >= 0 &&
 (ep->fifostart[1]) + ep->rxcount <
-ep->packey[1].len) {
+ep->packey[1].p.len) {
 TRACE("0x%08x, %d",  ep->fifostart[1], ep->rxcount );
 ep->fifostart[1] += ep->rxcount;
 ep->fifolen[1] = 0;
 
-ep->rxcount = MIN(ep->packey[0].len - (ep->fifostart[1]),
+ep->rxcount = MIN(ep->packey[0].p.len - (ep->fifostart[1]),
 ep->maxp[1]);
 
 ep->csr[1] &= ~MGC_M_RXCSR_H_REQPKT;
@@ -866,10 +879,11 @@ static void musb_rx_req(MUSBState *s, int epnum)
 #ifdef SETUPLEN_HACK
 /* Why should *we* do that instead of Linux?  */
 if (!epnum) {
-if (ep->packey[0].devaddr == 2)
+if (ep->packey[0].p.devaddr == 2) {
 total = MIN(s->setup_len, 8);
-else
+} else {
 total = MIN(s->setup_len, 64);
+}
 s->setup_len -= total;
 }
 #endif
-- 
1.7.1




[Qemu-devel] [PATCH 08/14] usb: control buffer fixes

2011-05-04 Thread Gerd Hoffmann
From: Hans de Goede 

Windows allows control transfers to pass up to 4k of data, so raise our
control buffer size to 4k. For control out transfers the usb core code copies
the control request data to a buffer before calling the device's handle_control
callback. Add a check for overflowing the buffer before copying the data.

Signed-off-by: Hans de Goede 
Signed-off-by: Gerd Hoffmann 
---
 hw/usb.c |6 ++
 hw/usb.h |2 +-
 2 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/hw/usb.c b/hw/usb.c
index 82a6217..d8c0a75 100644
--- a/hw/usb.c
+++ b/hw/usb.c
@@ -93,6 +93,12 @@ static int do_token_setup(USBDevice *s, USBPacket *p)
 s->setup_len = ret;
 s->setup_state = SETUP_STATE_DATA;
 } else {
+if (s->setup_len > sizeof(s->data_buf)) {
+fprintf(stderr,
+"usb_generic_handle_packet: ctrl buffer too small (%d > 
%zu)\n",
+s->setup_len, sizeof(s->data_buf));
+return USB_RET_STALL;
+}
 if (s->setup_len == 0)
 s->setup_state = SETUP_STATE_ACK;
 else
diff --git a/hw/usb.h b/hw/usb.h
index d3d755d..22bb338 100644
--- a/hw/usb.h
+++ b/hw/usb.h
@@ -167,7 +167,7 @@ struct USBDevice {
 
 int32_t state;
 uint8_t setup_buf[8];
-uint8_t data_buf[1024];
+uint8_t data_buf[4096];
 int32_t remote_wakeup;
 int32_t setup_state;
 int32_t setup_len;
-- 
1.7.1




Re: [Qemu-devel] [RFC 08/28] target-xtensa: implement conditional jumps

2011-05-04 Thread Richard Henderson
On 05/03/2011 05:59 PM, Max Filippov wrote:
> +int label = gen_new_label();
> +int inv = BRI12_M & 1;
> +
> +switch (BRI12_M & 2) {
> +case 0: /*BEQZ*/
> +tcg_gen_brcondi_i32(inv ? TCG_COND_EQ : TCG_COND_NE,
> +cpu_R[BRI12_S], 0, label);
> +break;
> +
> +case 2: /*BLTZ*/
> +tcg_gen_brcondi_i32(inv ? TCG_COND_LT : TCG_COND_GE,
> +cpu_R[BRI12_S], 0, label);
> +break;
> +}
> +gen_jumpi(dc, dc->pc + 4 + BRI12_IMM12_SE);
> +gen_set_label(label);
> +gen_jumpi(dc, dc->pc + 3);

It seems to me that this code could be cleaned up by extracting
the branching and jumpi'ing into a function.  There's a lot of
repetition here.

Also, once you do get around to using chained TB's, there'll be
only one place to have to update to get that to happen.


r~



[Qemu-devel] [PATCH 14/14] usb: mass storage fix

2011-05-04 Thread Gerd Hoffmann
Initialize scsi_len with zero when starting a new request, so any
stuff leftover from the previous request is cleared out.  This may
happen in case the data returned by the scsi command doesn't fit
into the buffer provided by the guest.

Signed-off-by: Gerd Hoffmann 
---
 hw/usb-msd.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/hw/usb-msd.c b/hw/usb-msd.c
index 93f4b78..bd1c3a4 100644
--- a/hw/usb-msd.c
+++ b/hw/usb-msd.c
@@ -364,6 +364,7 @@ static int usb_msd_handle_data(USBDevice *dev, USBPacket *p)
 DPRINTF("Command tag 0x%x flags %08x len %d data %d\n",
 s->tag, cbw.flags, cbw.cmd_len, s->data_len);
 s->residue = 0;
+s->scsi_len = 0;
 s->scsi_dev->info->send_command(s->scsi_dev, s->tag, cbw.cmd, 0);
 /* ??? Should check that USB and SCSI data transfer
directions match.  */
-- 
1.7.1




[Qemu-devel] [PATCH 13/14] usb: move complete callback to port ops

2011-05-04 Thread Gerd Hoffmann

Signed-off-by: Gerd Hoffmann 
---
 hw/usb-hub.c  |   14 ++
 hw/usb-msd.c  |4 ++--
 hw/usb-musb.c |   27 +--
 hw/usb-ohci.c |7 ++-
 hw/usb-uhci.c |7 +++
 hw/usb.h  |7 +++
 usb-linux.c   |2 +-
 7 files changed, 34 insertions(+), 34 deletions(-)

diff --git a/hw/usb-hub.c b/hw/usb-hub.c
index 3dd31ba..e0588f8 100644
--- a/hw/usb-hub.c
+++ b/hw/usb-hub.c
@@ -256,6 +256,19 @@ static void usb_hub_wakeup(USBDevice *dev)
 }
 }
 
+static void usb_hub_complete(USBDevice *dev, USBPacket *packet)
+{
+USBHubState *s = dev->port->opaque;
+
+/*
+ * Just pass it along upstream for now.
+ *
+ * If we ever inplement usb 2.0 split transactions this will
+ * become a little more complicated ...
+ */
+usb_packet_complete(&s->dev, packet);
+}
+
 static void usb_hub_handle_attach(USBDevice *dev)
 {
 USBHubState *s = DO_UPCAST(USBHubState, dev, dev);
@@ -524,6 +537,7 @@ static USBPortOps usb_hub_port_ops = {
 .attach = usb_hub_attach,
 .detach = usb_hub_detach,
 .wakeup = usb_hub_wakeup,
+.complete = usb_hub_complete,
 };
 
 static int usb_hub_initfn(USBDevice *dev)
diff --git a/hw/usb-msd.c b/hw/usb-msd.c
index 947fd3f..93f4b78 100644
--- a/hw/usb-msd.c
+++ b/hw/usb-msd.c
@@ -241,7 +241,7 @@ static void usb_msd_command_complete(SCSIBus *bus, int 
reason, uint32_t tag,
 s->mode = USB_MSDM_CSW;
 }
 s->packet = NULL;
-usb_packet_complete(p);
+usb_packet_complete(&s->dev, p);
 } else if (s->data_len == 0) {
 s->mode = USB_MSDM_CSW;
 }
@@ -257,7 +257,7 @@ static void usb_msd_command_complete(SCSIBus *bus, int 
reason, uint32_t tag,
usb_packet_complete returns.  */
 DPRINTF("Packet complete %p\n", p);
 s->packet = NULL;
-usb_packet_complete(p);
+usb_packet_complete(&s->dev, p);
 }
 }
 }
diff --git a/hw/usb-musb.c b/hw/usb-musb.c
index 30148e7..b30caeb 100644
--- a/hw/usb-musb.c
+++ b/hw/usb-musb.c
@@ -261,10 +261,12 @@
 
 static void musb_attach(USBPort *port);
 static void musb_detach(USBPort *port);
+static void musb_schedule_cb(USBDevice *dev, USBPacket *p);
 
 static USBPortOps musb_port_ops = {
 .attach = musb_attach,
 .detach = musb_detach,
+.complete = musb_schedule_cb,
 };
 
 typedef struct MUSBPacket MUSBPacket;
@@ -511,9 +513,11 @@ static inline void musb_cb_tick1(void *opaque)
 
 #define musb_cb_tick   (dir ? musb_cb_tick1 : musb_cb_tick0)
 
-static inline void musb_schedule_cb(USBPacket *packey, void *opaque, int dir)
+static inline void musb_schedule_cb(USBDevice *dev, USBPacket *packey)
 {
-MUSBEndPoint *ep = (MUSBEndPoint *) opaque;
+MUSBPacket *p = container_of(packey, MUSBPacket, p);
+MUSBEndPoint *ep = p->ep;
+int dir = p->dir;
 int timeout = 0;
 
 if (ep->status[dir] == USB_RET_NAK)
@@ -521,25 +525,15 @@ static inline void musb_schedule_cb(USBPacket *packey, 
void *opaque, int dir)
 else if (ep->interrupt[dir])
 timeout = 8;
 else
-return musb_cb_tick(opaque);
+return musb_cb_tick(ep);
 
 if (!ep->intv_timer[dir])
-ep->intv_timer[dir] = qemu_new_timer_ns(vm_clock, musb_cb_tick, 
opaque);
+ep->intv_timer[dir] = qemu_new_timer_ns(vm_clock, musb_cb_tick, ep);
 
 qemu_mod_timer(ep->intv_timer[dir], qemu_get_clock_ns(vm_clock) +
muldiv64(timeout, get_ticks_per_sec(), 8000));
 }
 
-static void musb_schedule0_cb(USBPacket *packey, void *opaque)
-{
-return musb_schedule_cb(packey, opaque, 0);
-}
-
-static void musb_schedule1_cb(USBPacket *packey, void *opaque)
-{
-return musb_schedule_cb(packey, opaque, 1);
-}
-
 static int musb_timeout(int ttype, int speed, int val)
 {
 #if 1
@@ -596,7 +590,6 @@ static inline void musb_packet(MUSBState *s, MUSBEndPoint 
*ep,
 ep->type[idx] >> 6, ep->interval[idx]);
 ep->interrupt[dir] = ttype == USB_ENDPOINT_XFER_INT;
 ep->delayed_cb[dir] = cb;
-cb = dir ? musb_schedule1_cb : musb_schedule0_cb;
 
 ep->packey[dir].p.pid = pid;
 /* A wild guess on the FADDR semantics... */
@@ -604,8 +597,6 @@ static inline void musb_packet(MUSBState *s, MUSBEndPoint 
*ep,
 ep->packey[dir].p.devep = ep->type[idx] & 0xf;
 ep->packey[dir].p.data = (void *) ep->buf[idx];
 ep->packey[dir].p.len = len;
-ep->packey[dir].p.complete_cb = cb;
-ep->packey[dir].p.complete_opaque = ep;
 ep->packey[dir].ep = ep;
 ep->packey[dir].dir = dir;
 
@@ -620,7 +611,7 @@ static inline void musb_packet(MUSBState *s, MUSBEndPoint 
*ep,
 }
 
 ep->status[dir] = ret;
-usb_packet_complete(&ep->packey[dir].p);
+usb_packet_complete(s->port.dev, &ep->packey[dir].p);
 }
 
 static void musb_tx_packet_complete(USBPacket *packey, void *opaque)
diff --git a/hw/usb-ohci.c b/hw/usb-ohci.c
index 7678cdb..8090c17 100644
--- a/hw/usb-ohci.c
+++ b/hw/usb-o

Re: [Qemu-devel] A Question

2011-05-04 Thread Peter Maydell
On 4 May 2011 16:26, Zhenkai Zhang  wrote:
> I want to emulate some code for ARM7TDMI. Does Qemu support this ARM type?

No, we don't emulate an ARM7TDMI. However depending on what your code
does it's possible that you might be able to get away with using the
ARM926 model. If you want to emulate a system image (rather than an
individual Linux application binary) you also need to consider what
SoC/device/peripherals the system image requires and whether QEMU
supports them: that is likely to be a bigger obstacle.

-- PMM



Re: [Qemu-devel] [RFC 11/28] target-xtensa: implement RST3 group

2011-05-04 Thread Richard Henderson
On 05/03/2011 05:59 PM, Max Filippov wrote:
> +case 2: /*SEXTu*/
> +HAS_OPTION(XTENSA_OPTION_MISC_OP);
> +{
> +TCGv_i32 tmp = tcg_temp_new_i32();
> +tcg_gen_shli_i32(tmp, cpu_R[RRR_S], 24 - RRR_T);
> +tcg_gen_sari_i32(cpu_R[RRR_R], tmp, 24 - RRR_T);
> +tcg_temp_free(tmp);

It's probably worth special-casing extensions from bit 7 and 15
as normal 8 and 16-bit sign-extensions.  Those are likely to be
99% of all extension operations actually performed.


r~



Re: [Qemu-devel] s390x kvm and smp

2011-05-04 Thread Christian Borntraeger
On 04/05/11 12:59, Jan Kiszka wrote:
> s390 just need to return a meaningful value from
> kvm_arch_process_async_events, e.g. env->halted, see other archs.

Yes indeed. This patch fixes smp for kvm on s390x.

Signed-off-by: Christian Borntraeger 

--- a/target-s390x/kvm.c
+++ b/target-s390x/kvm.c
@@ -172,7 +172,7 @@ void kvm_arch_post_run(CPUState *env, struct kvm_run *run)
 
 int kvm_arch_process_async_events(CPUState *env)
 {
-return 0;
+return env->halted;
 }
 
 void kvm_s390_interrupt_internal(CPUState *env, int type, uint32_t parm,



Re: [Qemu-devel] [RFC 12/28] target-xtensa: implement shifts (ST1 and RST1 groups)

2011-05-04 Thread Richard Henderson
On 05/03/2011 05:59 PM, Max Filippov wrote:
> +HAS_OPTION(XTENSA_OPTION_MISC_OP);
> +{
> +#define gen_bit_bisect(w) do { \
> +int label = gen_new_label(); \
> +tcg_gen_brcondi_i32(TCG_COND_LTU, tmp, 1 << (w), label); \
> +tcg_gen_shri_i32(tmp, tmp, (w)); \
> +tcg_gen_subi_i32(res, res, (w)); \
> +gen_set_label(label); \
> +} while (0)
> +
> +int label = gen_new_label();
> +TCGv_i32 res = tcg_temp_local_new_i32();
> +
> +tcg_gen_movi_i32(res, 32);
> +tcg_gen_brcondi_i32(
> +TCG_COND_EQ, cpu_R[RRR_S], 0, label);
> +{
> +TCGv_i32 tmp = tcg_temp_local_new_i32();
> +tcg_gen_mov_i32(tmp, cpu_R[RRR_S]);
> +tcg_gen_movi_i32(res, 31);
> +
> +gen_bit_bisect(16);
> +gen_bit_bisect(8);
> +gen_bit_bisect(4);
> +gen_bit_bisect(2);
> +gen_bit_bisect(1);
> +
> +tcg_temp_free(tmp);
> +}
> +gen_set_label(label);
> +tcg_gen_mov_i32(cpu_R[RRR_T], res);
> +tcg_temp_free(res);
> +#undef gen_bit_bisect

This instruction is probably right at the edge of the size restrictions
on the number of ops allowed to be emitted per guest insn.  It probably
makes more sense to move this to an out-of-line helper function.

Also note that this is implementable more efficiently on hosts that have
a count-leading-zeros function:

uint32_t HELPER(nsau)(uint32_t val)
{
return val ? clz32(val) : 32;
}

uint32_t HELPER(nsa)(int32_t val)
{
if (val < 0) {
val = ~val;
}
if (val == 0) {
return 31;
}
return clz32(val) - 1;
}

> +case 9: /*SRL*/
> +{
> +TCGv_i64 v = tcg_temp_new_i64();
> +tcg_gen_extu_i32_i64(v, cpu_R[RRR_T]);
> +gen_shift(shr);
> +}
> +break;
> +
> +case 10: /*SLL*/
> +{
> +TCGv_i64 v = tcg_temp_new_i64();
> +TCGv_i32 s = tcg_const_i32(32);
> +tcg_gen_sub_i32(s, s, cpu_SR[SAR]);
> +tcg_gen_extu_i32_i64(v, cpu_R[RRR_S]);
> +gen_shift_reg(shl, s);
> +tcg_temp_free(s);
> +}
> +break;
> +
> +case 11: /*SRA*/
> +{
> +TCGv_i64 v = tcg_temp_new_i64();
> +tcg_gen_ext_i32_i64(v, cpu_R[RRR_T]);
> +gen_shift(sar);
> +}

Are you implementing some of these as 64-bit shifts simply
to get a shift count of 32 correct?  While I admit that it's
probably the most efficient mechanism when the host is 64-bit,
it's somewhat less than clear.  You could stand to add some
commentary here about your choice.

As a future enhancement, it might be worthwhile to track any
known contents of SAR within the TB (see how other ports put
information about the state of the flags register in the 
DisassContext).  If you have a known value in the SAR, you
can emit the proper 32-bit shift directly.


r~



Re: [Qemu-devel] [RFC 18/28] target-xtensa: implement exceptions

2011-05-04 Thread Richard Henderson
On 05/03/2011 05:59 PM, Max Filippov wrote:
> +static void gen_check_privilege(DisasContext *dc)
> +{
> +if (option_enabled(dc, XTENSA_OPTION_MMU)) {
> +TCGv_i32 tmp = tcg_temp_new_i32();
> +int label = gen_new_label();
> +
> +tcg_gen_andi_i32(tmp, cpu_SR[PS], PS_EXCM);
> +tcg_gen_brcondi_i32(TCG_COND_EQ, tmp, PS_EXCM, label);
> +tcg_gen_andi_i32(tmp, cpu_SR[PS], PS_RING);
> +tcg_gen_brcondi_i32(TCG_COND_GEU, tmp, 0, label);
> +
> +gen_exception_cause(dc, PRIVILEGED_CAUSE);
> +
> +gen_set_label(label);
> +tcg_temp_free(tmp);
> +}
> +}

This is a case where you almost certainly want to check this 
condition inside QEMU and translate the opcode differently.

See cpu_get_tb_cpu_state, which sets bits in *flags.  These
flags can then be checked in tb->flags while translating.
At which point you'd avoid all the conditionalization on
the value in PS here in check_privilege and merely issue
the exception_cause.

The ARM port is a good example for testing these sorts of bits.


r~



Re: [Qemu-devel] [RFC 12/28] target-xtensa: implement shifts (ST1 and RST1 groups)

2011-05-04 Thread Max Filippov
>> +                    HAS_OPTION(XTENSA_OPTION_MISC_OP);
>> +                    {
>> +#define gen_bit_bisect(w) do { \
>> +        int label = gen_new_label(); \
>> +        tcg_gen_brcondi_i32(TCG_COND_LTU, tmp, 1 << (w), label); \
>> +        tcg_gen_shri_i32(tmp, tmp, (w)); \
>> +        tcg_gen_subi_i32(res, res, (w)); \
>> +        gen_set_label(label); \
>> +    } while (0)
>> +
>> +                        int label = gen_new_label();
>> +                        TCGv_i32 res = tcg_temp_local_new_i32();
>> +
>> +                        tcg_gen_movi_i32(res, 32);
>> +                        tcg_gen_brcondi_i32(
>> +                                TCG_COND_EQ, cpu_R[RRR_S], 0, label);
>> +                        {
>> +                            TCGv_i32 tmp = tcg_temp_local_new_i32();
>> +                            tcg_gen_mov_i32(tmp, cpu_R[RRR_S]);
>> +                            tcg_gen_movi_i32(res, 31);
>> +
>> +                            gen_bit_bisect(16);
>> +                            gen_bit_bisect(8);
>> +                            gen_bit_bisect(4);
>> +                            gen_bit_bisect(2);
>> +                            gen_bit_bisect(1);
>> +
>> +                            tcg_temp_free(tmp);
>> +                        }
>> +                        gen_set_label(label);
>> +                        tcg_gen_mov_i32(cpu_R[RRR_T], res);
>> +                        tcg_temp_free(res);
>> +#undef gen_bit_bisect
>
> This instruction is probably right at the edge of the size restrictions
> on the number of ops allowed to be emitted per guest insn.  It probably
> makes more sense to move this to an out-of-line helper function.
>
> Also note that this is implementable more efficiently on hosts that have
> a count-leading-zeros function:
>
> uint32_t HELPER(nsau)(uint32_t val)
> {
>    return val ? clz32(val) : 32;
> }
>
> uint32_t HELPER(nsa)(int32_t val)
> {
>    if (val < 0) {
>        val = ~val;
>    }
>    if (val == 0) {
>        return 31;
>    }
>    return clz32(val) - 1;
> }

Thanks for the hint, this way it looks much better.

>> +            case 9: /*SRL*/
>> +                {
>> +                    TCGv_i64 v = tcg_temp_new_i64();
>> +                    tcg_gen_extu_i32_i64(v, cpu_R[RRR_T]);
>> +                    gen_shift(shr);
>> +                }
>> +                break;
>> +
>> +            case 10: /*SLL*/
>> +                {
>> +                    TCGv_i64 v = tcg_temp_new_i64();
>> +                    TCGv_i32 s = tcg_const_i32(32);
>> +                    tcg_gen_sub_i32(s, s, cpu_SR[SAR]);
>> +                    tcg_gen_extu_i32_i64(v, cpu_R[RRR_S]);
>> +                    gen_shift_reg(shl, s);
>> +                    tcg_temp_free(s);
>> +                }
>> +                break;
>> +
>> +            case 11: /*SRA*/
>> +                {
>> +                    TCGv_i64 v = tcg_temp_new_i64();
>> +                    tcg_gen_ext_i32_i64(v, cpu_R[RRR_T]);
>> +                    gen_shift(sar);
>> +                }
>
> Are you implementing some of these as 64-bit shifts simply
> to get a shift count of 32 correct?  While I admit that it's
> probably the most efficient mechanism when the host is 64-bit,
> it's somewhat less than clear.  You could stand to add some
> commentary here about your choice.

Yes, possibility of indirect 32 bit shift was the only reason for that.
Will document that.

> As a future enhancement, it might be worthwhile to track any
> known contents of SAR within the TB (see how other ports put
> information about the state of the flags register in the
> DisassContext).  If you have a known value in the SAR, you
> can emit the proper 32-bit shift directly.

To track immediate values written to SAR? You mean that there may be
some performance difference of fixed size shift vs indirect shift and
TCG is able to tell them apart?

Thanks.
-- Max



Re: [Qemu-devel] [RFC 18/28] target-xtensa: implement exceptions

2011-05-04 Thread Richard Henderson
On 05/04/2011 09:33 AM, Richard Henderson wrote:
> This is a case where you almost certainly want to check this 
> condition inside QEMU and translate the opcode differently.
> 
> See cpu_get_tb_cpu_state, which sets bits in *flags.  These
> flags can then be checked in tb->flags while translating.
> At which point you'd avoid all the conditionalization on
> the value in PS here in check_privilege and merely issue
> the exception_cause.
> 
> The ARM port is a good example for testing these sorts of bits.

Actually, while the tb flags are useful, privileged instructions
are usually checked by testing mmu_index, since we already have
to generate different code for the TB based on which TLB entry we
need to access.


r~



Re: [Qemu-devel] s390x kvm and smp

2011-05-04 Thread Alexander Graf




Am 04.05.2011 um 18:13 schrieb Christian Borntraeger :

> On 04/05/11 12:59, Jan Kiszka wrote:
>> s390 just need to return a meaningful value from
>> kvm_arch_process_async_events, e.g. env->halted, see other archs.
> 
> Yes indeed. This patch fixes smp for kvm on s390x.
> 
> Signed-off-by: Christian Borntraeger 

Now give it a proper patch description and I'll get it in through my tree :)

Alex

> 



[Qemu-devel] [Bug 723871] Re: qemu-kvm-0.14.0 Aborts with -vga qxl

2011-05-04 Thread Boris Derzhavets
@Serge,
  Sorry, but answer is no.  I just learned how dh_make and dpkg-buildpackage 
works , picked up your's debian folder.
Updated debian/patches/series  and changelog . built new debian package ( based 
on new qemu-kvm-spice-0.14.0+noroms_0ubuntu4qxl3.orig.tar.gz)  due to three 
recent commits to upstream branch spice.v35 were done 
by Gerd Hoffmann and seemed  to solve the issue. 
  My major concern is port to Ubuntu spice-gtk 0.6 ( with python bindings) . It 
requires GLIBC 2.14 (gtk2-devel >= 2.14).
I've installed via alienating 6 fedora's packages ( i.e. ignoring dependencies 
) /usr/lib64/python2.7/dist-packages/SpiceClientGtk.so and VM's window got 
opened. Fixing complains one by one i got stuck when libc.so.6 was reported too 
old  ( GLIBC 2.13) . You are going to switch to 2.14 only on 11.10 as far as i 
know. So , i should wait for alpha.

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

Title:
  qemu-kvm-0.14.0 Aborts with -vga qxl

Status in QEMU:
  Confirmed
Status in “libvirt” package in Ubuntu:
  Triaged
Status in “qemu-kvm” package in Ubuntu:
  Fix Released

Bug description:
  Host CPU is Core i7 Q820.  KVM is from 2.6.35-gentoo-r5 kernel (x86_64).
  Host has spice-0.7.2 and spice-protocol-0.7.0.
  Guest is Windows XP SP3 with qxl driver 0.6.1, virtio-serial 1.1.6 and 
vdagent 0.6.3.

  qemu-kvm is started like so:
  qemu-system-x86_64 -cpu host -enable-kvm -pidfile /home/rick/qemu/hds/wxp.pid 
-drive 
file=/home/rick/qemu/hds/wxp.raw,if=virtio,media=disk,aio=native,snapshot=on -m 
768 -name WinXP -net nic,model=virtio -net user -localtime -usb -vga qxl 
-device virtio-serial -chardev spicevmc,name=vdagent,id=vdagent -device 
virtserialport,chardev=vdagent,name=com.redhat.spice.0 -spice 
port=1234,disable-ticketing -monitor stdio
  and crashes with:
  qemu-system-x86_64: /home/rick/qemu/src/qemu-kvm-0.14.0/qemu-kvm.c:1724: 
kvm_mutex_unlock: Assertion `!cpu_single_env' failed.
  Aborted

  If I use -no-kvm, it works fine.  If I use -vga std, it works fine.
  -enable-kvm and -vga qxl crashes.



Re: [Qemu-devel] [PATCH v2] Import Linux headers for KVM and vhost

2011-05-04 Thread Andreas Färber

Am 04.05.2011 um 12:28 schrieb Jan Kiszka:


On 2011-05-03 22:22, Peter Maydell wrote:

On 3 May 2011 17:48, Jan Kiszka  wrote:

+++ b/scripts/update-linux-headers.sh



+rm -rf $output/include/linux/*


Given that updating the kernel headers will blow away large
subsets of include/ like this, maybe we should use a less generic
name than "include", so it's clear that it's just a set of
automatically maintained and updated files, rather than
a good place to put random QEMU header files?

kernel-headers/ seems like an obvious choice.


[...] these suggestion all make sense. I've incorporated them.


If we're talking about a new directory inside the QEMU tree, mind to  
name it linux-headers or so? There are other kernels besides The One. :)


Andreas



Re: [Qemu-devel] [PATCH v2] Import Linux headers for KVM and vhost

2011-05-04 Thread Jan Kiszka
On 2011-05-04 19:58, Andreas Färber wrote:
> Am 04.05.2011 um 12:28 schrieb Jan Kiszka:
> 
>> On 2011-05-03 22:22, Peter Maydell wrote:
>>> On 3 May 2011 17:48, Jan Kiszka  wrote:
 +++ b/scripts/update-linux-headers.sh
> 
 +rm -rf $output/include/linux/*
>>>
>>> Given that updating the kernel headers will blow away large
>>> subsets of include/ like this, maybe we should use a less generic
>>> name than "include", so it's clear that it's just a set of
>>> automatically maintained and updated files, rather than
>>> a good place to put random QEMU header files?
>>>
>>> kernel-headers/ seems like an obvious choice.
>>
>> [...] these suggestion all make sense. I've incorporated them.
> 
> If we're talking about a new directory inside the QEMU tree, mind to  
> name it linux-headers or so? There are other kernels besides The One. :)

Already called it precisely like this. :) I will re-post my series when
the licensing things are clarified.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux



Re: [Qemu-devel] [PATCH 6/6] PPC: Qdev'ify e500 pci

2011-05-04 Thread Blue Swirl
On Mon, May 2, 2011 at 6:03 PM, Alexander Graf  wrote:
> The e500 PCI controller isn't qdev'ified yet. This leads to severe issues
> when running with -drive.
>
> To be able to use a virtio disk with an e500 VM, let's convert the PCI
> controller over to qdev.
>
> Signed-off-by: Alexander Graf 
>
> ---
>
> v2 -> v3:
>
>  - rebase to current code base
>  - fix endian issue
>  - use sysbus helpers
> ---
>  hw/ppce500_pci.c |  112 
> +++---
>  1 files changed, 73 insertions(+), 39 deletions(-)
>
> diff --git a/hw/ppce500_pci.c b/hw/ppce500_pci.c
> index 83a20e4..88bc759 100644
> --- a/hw/ppce500_pci.c
> +++ b/hw/ppce500_pci.c
> @@ -73,11 +73,11 @@ struct pci_inbound {
>  };
>
>  struct PPCE500PCIState {
> +    PCIHostState pci_state;
>     struct pci_outbound pob[PPCE500_PCI_NR_POBS];
>     struct pci_inbound pib[PPCE500_PCI_NR_PIBS];
>     uint32_t gasket_time;
> -    PCIHostState pci_state;
> -    PCIDevice *pci_dev;
> +    uint64_t base_addr;

This does not seem to be used. Also devices shouldn't care about their
base addresses.



Re: [Qemu-devel] [PATCH 0/6] PPC: Add FSL (e500) MMU emulation v3

2011-05-04 Thread Blue Swirl
On Mon, May 2, 2011 at 6:03 PM, Alexander Graf  wrote:
> In a global effort to get rid of KVM-only targets, this is the next
> important piece of the puzzle: e500 emulation :).
>
> We had support for running an e500 KVM guest for a while now, but the
> code could not be tested without a real e500 machine, because it required
> KVM to work. This patchset adds emulation for the e500 MMU, enabling
> anyone to use the MPC8544DS emulation.

I had some comments to 6/6, otherwise all look fine to me.



Re: [Qemu-devel] [RFC 12/28] target-xtensa: implement shifts (ST1 and RST1 groups)

2011-05-04 Thread Richard Henderson
On 05/04/2011 09:39 AM, Max Filippov wrote:
> To track immediate values written to SAR? You mean that there may be
> some performance difference of fixed size shift vs indirect shift and
> TCG is able to tell them apart?

Well, not really fixed vs indirect, but if you know that the value
in the SAR register is in the right range, you can avoid using a
64-bit shift.

For instance,

SSL ar2
SLL ar0, ar1

could be implemented with

tcg_gen_sll_i32(ar0, ar1, ar2);

assuming we have enough context.

Let us decompose the SAR register into two parts, storing both the
true value, and 32-value.

struct DisasContext {
// Current Stuff
// ...

// When valid, holds 32-SAR.
TCGv sar_m32;
bool sar_m32_alloc;
bool sar_m32_valid;
bool sar_5bit;
};

At the beginning of the TB:

TCGV_UNUSED_I32(dc->sar_m32);
dc->sar_m32_alloc = false;
dc->sar_m32_valid = false;
dc->sar_5bit = false;



static void gen_set_sra_m32(DisasContext *dc, TCGv val)
{
if (!dc->sar_m32_alloc) {
dc->sar_m32_alloc = true;
dc->sar_m32 = tcg_temp_local_new_i32();
}
dc->sar_m32_valid = true;

/* Clear 5 bit because the SAR value could be 32.  */
dc->sar_5bit = false;

tcg_gen_movi_i32(cpu_SR[SAR], 32);
tcg_gen_sub_i32(cpu_SR[SAR], cpu_SR[SAR], val);
tcg_gen_mov_i32(dc->sar_m32, val);
}

static void gen_set_sra(DisasContext *dc, TCGv val, bool is_5bit)
{
if (dc->sar_m32_alloc && dc->sar_m32_valid) {
tcg_gen_discard_i32(dc->sar_m32);
}
dc->sar_m32_valid = false;
dc->sar_5bit = is_5bit;

tcg_gen_mov_i32(cpu_SR[SAR], val);
}

/* SSL */
tcg_gen_andi_i32(tmp, cpu_R[AS], 31);
gen_set_sra_m32(dc, tmp);
break;

/* SRL */
tcg_gen_andi_i32(tmp, cpu_R[AS], 31);
gen_set_sra(dc, tmp, true);
break;

/* WSR.SAR */
tcg_gen_andi_i32(tmp, cpu_R[AS], 63);
gen_set_sra(dc, tmp, false);
break;

/* SSAI */
tcg_gen_movi_i32(tmp, constant);
gen_gen_sra(dc, tmp, true);
break;

/* SLL */
if (dc->sar_m32_valid) {
tcg_gen_sll_i32(cpu_R[AR], cpu_R[AS], dc->sar_m32);
} else {
/* your existing 64-bit shift emulation.  */
}
break;

/* SRL */
if (dc->sar_5bit) {
tcg_gen_srl_i32(cpu_R[AR], cpu_R[AS], cpu_SR[SAR]);
} else {
/* your existing 64-bit shift emulation.  */
}


A couple of points: The use of the local temp avoids problems with
intervening insns that might generate branch opcodes.  For the
simplest cases, as with the case at the start of the message, we
ought to be able to propagate the values into the TCG shift insn
directly.

Does that make sense?


r~



Re: [Qemu-devel] [PATCH] vfio: Fix free in dma mapping error path

2011-05-04 Thread Tom Lyon
On Friday, April 29, 2011 03:05:54 pm Alex Williamson wrote:
> This is allocated via vmalloc, so needs vfree, not kfree.
> 
> Signed-off-by: Alex Williamson 
> ---
> 
>  drivers/vfio/vfio_dma.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/vfio/vfio_dma.c b/drivers/vfio/vfio_dma.c
> index cee1a25..4a488b6 100644
> --- a/drivers/vfio/vfio_dma.c
> +++ b/drivers/vfio/vfio_dma.c
> @@ -322,7 +322,7 @@ int vfio_dma_map_common(struct vfio_listener *listener,
>   if (ret != npage) {
>   printk(KERN_ERR "%s: get_user_pages_fast returns %d, not %d\n",
>   __func__, ret, npage);
> - kfree(pages);
> + vfree(pages);
>   ret = -EFAULT;
>   goto out_lock;
>   }
Applied. Thanks.



Re: [Qemu-devel] [PATCH 0/8] cpu interrupt cleanup

2011-05-04 Thread Blue Swirl
On Sun, May 1, 2011 at 1:24 AM, Richard Henderson  wrote:
> Blue Swirl pointed out that CPU_INTERRUPT_TIMER was unused,
> and should therefore be remove.  This is a logical extension
> of that, making all target specific cpu interrupts really be
> private to the target.
>
> This will allow new ports to define external cpu interrupts
> as needed without having to modify generic code.

The patches don't apply, please rebase. Please also fix the tab and
trailing whitespace problems spotted by scripts/checkpatch.pl while at
it.



Re: [Qemu-devel] [PATCH 0/3]: QMP: Introduce inject-nmi command

2011-05-04 Thread Blue Swirl
On Mon, May 2, 2011 at 6:57 PM, Luiz Capitulino  wrote:
> On Sat, 30 Apr 2011 09:33:15 +0300
> Blue Swirl  wrote:
>
>> On Sat, Apr 30, 2011 at 1:40 AM, Luiz Capitulino  
>> wrote:
>> > This series introduces the inject-nmi command for QMP, which sends an
>> > NMI to _all_ guest's CPUs.
>> >
>> > Also note that this series changes the human monitor nmi command to use
>> > the QMP implementation, which means that it now has a DIFFERENT behavior.
>> > Please, check patch 3/3 for details.
>>
>> As discussed earlier, please change the QMP version for future
>> expandability so that instead of single command 'inject-nmi', 'inject'
>> takes parameter 'nmi'. HMP command 'nmi' can remain for now, but
>> 'inject' should be added.
>
> I'm not sure I agree with this, because we risky overloading 'inject' the
> same way we did with the 'change' command.
>
> What's 'inject' supposed to do in the future?

Inject other IRQs, for example inject nmi could become an alias to
something like
inject /apic@fee0:l1int
which would be a shorthand for
raise /apic@fee0:l1int
lower /apic@fee0:l1int

I think we only need a registration framework for IRQs and other signals.



Re: [Qemu-devel] [RFC 20/28] target-xtensa: implement windowed registers

2011-05-04 Thread Blue Swirl
On Wed, May 4, 2011 at 3:59 AM, Max Filippov  wrote:
> See ISA, 4.7.1 for details.
>
> Physical registers and currently visible window are separate fields in
> CPUEnv. Only current window is accessible to TCG. On operations that
> change window base helpers copy current window to and from physical
> registers.

I'm not sure how the register windows work, but maybe you could use
the same trick used for Sparc. There is a pool of registers
(env->regbase[]), a register window pointer (env->regwptr,
cpu_regwptr) tracks which are the currently accessible ones. The
advantage is to avoid copying (not entirely for Sparc due to the
window overlap).



Re: [Qemu-devel] [RFC 19/28] target-xtensa: implement RST2 group (32 bit mul/div/rem)

2011-05-04 Thread Blue Swirl
On Wed, May 4, 2011 at 3:59 AM, Max Filippov  wrote:
> Signed-off-by: Max Filippov 
> ---
>  target-xtensa/translate.c |   60 
> -
>  1 files changed, 59 insertions(+), 1 deletions(-)
>
> diff --git a/target-xtensa/translate.c b/target-xtensa/translate.c
> index faf1adc..d635229 100644
> --- a/target-xtensa/translate.c
> +++ b/target-xtensa/translate.c
> @@ -793,7 +793,65 @@ static void disas_xtensa_insn(DisasContext *dc)
>             break;
>
>         case 2: /*RST2*/
> -            TBD();
> +            if (_OP2 >= 12) {
> +                HAS_OPTION(XTENSA_OPTION_32_BIT_IDIV);
> +                int label = gen_new_label();
> +                tcg_gen_brcondi_i32(TCG_COND_NE, cpu_R[RRR_T], 0, label);
> +                gen_exception_cause(dc, INTEGER_DIVIE_BY_ZERO_CAUSE);

DIVIE?



Re: [Qemu-devel] Build breakage on OpenSolaris - softfloat

2011-05-04 Thread Andreas Färber


On 1 May 2011 16:39, Andreas Färber  wrote:
   

>  Looks like an issue with make_floatx80(). Any ideas?
 
>  $ gcc --version

>  gcc (GCC) 3.4.3 (csl-sol210-3_4-20050802)
 

Hmm. I did a test build on x86 host with gcc 3.3.5 and gcc 3.4.6,
which were both OK, so it looks like it might be solaris
specific.


Same with gcc 4.3.2:

$ gcc-4.3.2 --version
gcc-4.3.2 (GCC) 4.3.2
Copyright (C) 2008 Free Software Foundation, Inc.
Dies ist freie Software; die Kopierbedingungen stehen in den Quellen. Es
gibt KEINE Garantie; auch nicht für MARKTGÄNGIGKEIT oder FÜR SPEZIELLE 
ZWECKE.


This one is on OpenSolaris 2010.05 snv_134b (previously on 2009.06 
snv_111b).


Andreas



Re: [Qemu-devel] [RFC 24/28] target-xtensa: implement SIMCALL

2011-05-04 Thread Blue Swirl
On Wed, May 4, 2011 at 3:59 AM, Max Filippov  wrote:
> Tensilica iss provides support for applications running in freestanding
> environment through SIMCALL command. It is used by Tensilica libc to
> access argc/argv, for file I/O, etc.
>
> Signed-off-by: Max Filippov 
> ---
>  target-xtensa/helpers.h   |    1 +
>  target-xtensa/op_helper.c |    7 ++
>  target-xtensa/simcall.c   |  157 
> +
>  target-xtensa/translate.c |    2 +-
>  4 files changed, 166 insertions(+), 1 deletions(-)
>  create mode 100644 target-xtensa/simcall.c
>
> diff --git a/target-xtensa/helpers.h b/target-xtensa/helpers.h
> index 7e212a3..55eb0d8 100644
> --- a/target-xtensa/helpers.h
> +++ b/target-xtensa/helpers.h
> @@ -11,6 +11,7 @@ DEF_HELPER_2(window_check, void, i32, i32)
>  DEF_HELPER_0(restore_owb, void)
>  DEF_HELPER_1(movsp, void, i32)
>  DEF_HELPER_1(wsr_lend, void, i32)
> +DEF_HELPER_0(simcall, void)
>  DEF_HELPER_0(dump_state, void)
>
>  #include "def-helper.h"
> diff --git a/target-xtensa/op_helper.c b/target-xtensa/op_helper.c
> index f0690ee..68b1526 100644
> --- a/target-xtensa/op_helper.c
> +++ b/target-xtensa/op_helper.c
> @@ -264,6 +264,13 @@ void HELPER(wsr_lend)(uint32_t v)
>     }
>  }
>
> +#include "simcall.c"
> +
> +void HELPER(simcall)(void)
> +{
> +    simcall(env->regs);

Maybe this should be enabled only with -semihosting parameter, like
ARM and m68k. Consider for example what could happen if this would be
issued from userland when used with an OS.

> +}
> +
>  void HELPER(dump_state)(void)
>  {
>     cpu_dump_state(env, stderr, fprintf, 0);
> diff --git a/target-xtensa/simcall.c b/target-xtensa/simcall.c
> new file mode 100644
> index 000..3446275
> --- /dev/null
> +++ b/target-xtensa/simcall.c
> @@ -0,0 +1,157 @@
> +/*
> + * Copyright (c) 2011, Max Filippov, Motorola Solutions, Inc.
> + * All rights reserved.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions are 
> met:
> + *     * Redistributions of source code must retain the above copyright
> + *       notice, this list of conditions and the following disclaimer.
> + *     * Redistributions in binary form must reproduce the above copyright
> + *       notice, this list of conditions and the following disclaimer in the
> + *       documentation and/or other materials provided with the distribution.
> + *     * Neither the name of the Motorola Solutions nor the
> + *       names of its contributors may be used to endorse or promote products
> + *       derived from this software without specific prior written 
> permission.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS 
> IS"
> + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
> + * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
> + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR 
> SERVICES;
> + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED 
> AND
> + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 
> THIS
> + * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +enum {
> +    SYS_exit = 1,
> +    SYS_read = 3,
> +    SYS_write = 4,
> +    SYS_open = 5,
> +    SYS_close = 6,
> +
> +    SYS_argc = 1000,
> +    SYS_argv_sz = 1001,
> +    SYS_argv = 1002,
> +    SYS_memset = 1004,

I think these names may easily conflict with system defines, please
use for example TARGET_SYS_exit etc.

> +};
> +
> +static void simcall(uint32_t regs[16])
> +{
> +    switch (regs[2]) {
> +    case SYS_exit:
> +        printf("exit(%d)\n", regs[3]);
> +        exit(regs[3]);
> +        break;
> +
> +    case SYS_read:
> +        {
> +            target_phys_addr_t len = regs[5];
> +            void *buf = cpu_physical_memory_map(regs[4], &len, 1);
> +
> +            if (buf) {
> +                regs[2] = read(regs[3], buf, len);
> +                regs[3] = errno;
> +                cpu_physical_memory_unmap(buf, len, 1, len);
> +            } else {
> +                regs[2] = -1;
> +                regs[3] = 0;
> +            }
> +        }
> +        break;
> +
> +    case SYS_write:
> +        {
> +            target_phys_addr_t len = regs[5];
> +            void *buf = cpu_physical_memory_map(regs[4], &len, 0);
> +
> +            if (buf) {
> +                regs[2] = write(regs[3], buf, len);
> +                regs[3] = errno;
> +                cpu_physical_memory_unmap(buf, len, 0, len);
> +            } else {
> +                regs[2] = -1;
> +                regs[3] = 0;
> +     

Re: [Qemu-devel] [RFC 01/28] target-xtensa: add target stubs

2011-05-04 Thread Blue Swirl
On Wed, May 4, 2011 at 3:59 AM, Max Filippov  wrote:
> Signed-off-by: Max Filippov 
> ---
>  Makefile.target           |    2 +
>  arch_init.c               |    2 +
>  arch_init.h               |    1 +
>  cpu-exec.c                |   10 +
>  elf.h                     |    2 +
>  hw/xtensa_pic.c           |   11 ++
>  target-xtensa/cpu.h       |   84 
> +
>  target-xtensa/exec.h      |   55 +
>  target-xtensa/helper.c    |   74 +++
>  target-xtensa/machine.c   |   38 
>  target-xtensa/op_helper.c |   51 +++
>  target-xtensa/translate.c |   67 +++
>  12 files changed, 397 insertions(+), 0 deletions(-)
>  create mode 100644 hw/xtensa_pic.c
>  create mode 100644 target-xtensa/cpu.h
>  create mode 100644 target-xtensa/exec.h
>  create mode 100644 target-xtensa/helper.c
>  create mode 100644 target-xtensa/machine.c
>  create mode 100644 target-xtensa/op_helper.c
>  create mode 100644 target-xtensa/translate.c
>
> diff --git a/Makefile.target b/Makefile.target
> index 21f864a..7e7afd2 100644
> --- a/Makefile.target
> +++ b/Makefile.target
> @@ -366,6 +366,8 @@ obj-s390x-y = s390-virtio-bus.o s390-virtio.o
>
>  obj-alpha-y = alpha_palcode.o
>
> +obj-xtensa-y += xtensa_pic.o
> +
>  main.o: QEMU_CFLAGS+=$(GPROF_CFLAGS)
>
>  monitor.o: hmp-commands.h qmp-commands.h
> diff --git a/arch_init.c b/arch_init.c
> index 0c09f91..c1f0005 100644
> --- a/arch_init.c
> +++ b/arch_init.c
> @@ -78,6 +78,8 @@ const char arch_config_name[] = CONFIG_QEMU_CONFDIR 
> "/target-" TARGET_ARCH ".con
>  #define QEMU_ARCH QEMU_ARCH_SH4
>  #elif defined(TARGET_SPARC)
>  #define QEMU_ARCH QEMU_ARCH_SPARC
> +#elif defined(TARGET_XTENSA)
> +#define QEMU_ARCH QEMU_ARCH_XTENSA
>  #endif
>
>  const uint32_t arch_type = QEMU_ARCH;
> diff --git a/arch_init.h b/arch_init.h
> index 86ebc14..61ad347 100644
> --- a/arch_init.h
> +++ b/arch_init.h
> @@ -17,6 +17,7 @@ enum {
>     QEMU_ARCH_S390X = 512,
>     QEMU_ARCH_SH4 = 1024,
>     QEMU_ARCH_SPARC = 2048,
> +    QEMU_ARCH_XTENSA = 4096,
>  };
>
>  extern const uint32_t arch_type;
> diff --git a/cpu-exec.c b/cpu-exec.c
> index 395cd8c..a692daf 100644
> --- a/cpu-exec.c
> +++ b/cpu-exec.c
> @@ -275,6 +275,7 @@ int cpu_exec(CPUState *env1)
>  #elif defined(TARGET_SH4)
>  #elif defined(TARGET_CRIS)
>  #elif defined(TARGET_S390X)
> +#elif defined(TARGET_XTENSA)
>     /* X */
>  #else
>  #error unsupported target CPU
> @@ -348,6 +349,8 @@ int cpu_exec(CPUState *env1)
>                     do_interrupt(0);
>  #elif defined(TARGET_S390X)
>                     do_interrupt(env);
> +#elif defined(TARGET_XTENSA)
> +                    do_interrupt(env);
>  #endif
>                     env->exception_index = -1;
>  #endif
> @@ -568,6 +571,12 @@ int cpu_exec(CPUState *env1)
>                         do_interrupt(env);
>                         next_tb = 0;
>                     }
> +#elif defined(TARGET_XTENSA)
> +                    if (interrupt_request & CPU_INTERRUPT_HARD) {
> +                        env->exception_index = EXC_IRQ;
> +                        do_interrupt(env);
> +                        next_tb = 0;
> +                    }
>  #endif
>                    /* Don't use the cached interupt_request value,
>                       do_interrupt may have updated the EXITTB flag. */
> @@ -696,6 +705,7 @@ int cpu_exec(CPUState *env1)
>  #elif defined(TARGET_ALPHA)
>  #elif defined(TARGET_CRIS)
>  #elif defined(TARGET_S390X)
> +#elif defined(TARGET_XTENSA)
>     /* X */
>  #else
>  #error unsupported target CPU
> diff --git a/elf.h b/elf.h
> index ffcac7e..2e05d34 100644
> --- a/elf.h
> +++ b/elf.h
> @@ -125,6 +125,8 @@ typedef int64_t  Elf64_Sxword;
>  #define EM_MICROBLAZE      189
>  #define EM_MICROBLAZE_OLD  0xBAAB
>
> +#define EM_XTENSA   94      /* Tensilica Xtensa */
> +
>  /* This is the info that is needed to parse the dynamic section of the file 
> */
>  #define DT_NULL                0
>  #define DT_NEEDED      1
> diff --git a/hw/xtensa_pic.c b/hw/xtensa_pic.c
> new file mode 100644
> index 000..5ff1697
> --- /dev/null
> +++ b/hw/xtensa_pic.c
> @@ -0,0 +1,11 @@
> +#include "hw.h"
> +#include "pc.h"
> +
> +/* Stub functions for hardware that doesn't exist.  */
> +void pic_info(Monitor *mon)
> +{
> +}
> +
> +void irq_info(Monitor *mon)
> +{
> +}
> diff --git a/target-xtensa/cpu.h b/target-xtensa/cpu.h
> new file mode 100644
> index 000..ef6881a
> --- /dev/null
> +++ b/target-xtensa/cpu.h
> @@ -0,0 +1,84 @@
> +/*
> + * Copyright (c) 2011, Max Filippov, Motorola Solutions, Inc.
> + * All rights reserved.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions are 
> met:
> + *     * Redistributions of source code must retain the above copyright
> + *       notice, this list of conditions and 

Re: [Qemu-devel] [RFC 20/28] target-xtensa: implement windowed registers

2011-05-04 Thread Blue Swirl
On Wed, May 4, 2011 at 11:07 PM, Richard Henderson  wrote:
> On 05/04/2011 12:35 PM, Blue Swirl wrote:
>> On Wed, May 4, 2011 at 3:59 AM, Max Filippov  wrote:
>>> See ISA, 4.7.1 for details.
>>>
>>> Physical registers and currently visible window are separate fields in
>>> CPUEnv. Only current window is accessible to TCG. On operations that
>>> change window base helpers copy current window to and from physical
>>> registers.
>>
>> I'm not sure how the register windows work, but maybe you could use
>> the same trick used for Sparc. There is a pool of registers
>> (env->regbase[]), a register window pointer (env->regwptr,
>> cpu_regwptr) tracks which are the currently accessible ones. The
>> advantage is to avoid copying (not entirely for Sparc due to the
>> window overlap).
>
> Sparc loses out on some TCG optimizations because of that, although
> to be fair the most effective of these are still in Aurlien's trees.

Interesting. Which optimizations? What trees? How would you implement
the register windows then?



Re: [Qemu-devel] [RFC 20/28] target-xtensa: implement windowed registers

2011-05-04 Thread Richard Henderson
On 05/04/2011 12:35 PM, Blue Swirl wrote:
> On Wed, May 4, 2011 at 3:59 AM, Max Filippov  wrote:
>> See ISA, 4.7.1 for details.
>>
>> Physical registers and currently visible window are separate fields in
>> CPUEnv. Only current window is accessible to TCG. On operations that
>> change window base helpers copy current window to and from physical
>> registers.
> 
> I'm not sure how the register windows work, but maybe you could use
> the same trick used for Sparc. There is a pool of registers
> (env->regbase[]), a register window pointer (env->regwptr,
> cpu_regwptr) tracks which are the currently accessible ones. The
> advantage is to avoid copying (not entirely for Sparc due to the
> window overlap).

Sparc loses out on some TCG optimizations because of that, although
to be fair the most effective of these are still in Aurlien's trees.

That said, I still would not recommend a new port to follow suit.


r~



Re: [Qemu-devel] [RFC 20/28] target-xtensa: implement windowed registers

2011-05-04 Thread Richard Henderson
On 05/04/2011 01:13 PM, Blue Swirl wrote:
>> Sparc loses out on some TCG optimizations because of that, although
>> to be fair the most effective of these are still in Aurlien's trees.
> 
> Interesting. Which optimizations? What trees? How would you implement
> the register windows then?

Constant propagation for one.  This one in particular would allow the
tcg backend to see full constants, rather than seeing the constant 
being built up from risc instructions.

  git://git.aurel32.net/qemu.git tcg-optimizations

I have previously built on this to streamline the code generated for
target load/store operations.  We currently always force the address
into a register and do the arithmetic on that.  If we have the full
constant for the address, we can push the parts of that constant into
the TLB load etc.

  git://repo.or.cz/qemu/rth.git tcg-const-addr-1

As for how to implement the register windows...

I'm not 100% sure.  The easiest way is indeed to copy values to and
fro a consolidated register file, as Max is doing here.  I've also
experimented briefly with extending TCG to handle "indirect" registers.
Where the register values are consistent as far as the TCG optimizers
are concerned, but when it comes time to expand the code, we perform
the indirect read, just as you currently expand by hand ahead of time.
I never got either solution totally working for sparc.


r~



Re: [Qemu-devel] [RFC 24/28] target-xtensa: implement SIMCALL

2011-05-04 Thread Peter Maydell
On 4 May 2011 20:48, Blue Swirl  wrote:
> On Wed, May 4, 2011 at 3:59 AM, Max Filippov  wrote:
>> Tensilica iss provides support for applications running in freestanding
>> environment through SIMCALL command. It is used by Tensilica libc to
>> access argc/argv, for file I/O, etc.
>>
>> Signed-off-by: Max Filippov 
>> ---
>>  target-xtensa/helpers.h   |    1 +
>>  target-xtensa/op_helper.c |    7 ++
>>  target-xtensa/simcall.c   |  157 
>> +

The existing simcall/semihosting implementations
are in arm-semi.c and m68k-semi.c in the top level
directory. I think xtensa should do the same
(unless somebody wants to propose moving arm and
m68k instead...)

>> +void HELPER(simcall)(void)
>> +{
>> +    simcall(env->regs);
>
> Maybe this should be enabled only with -semihosting parameter, like
> ARM and m68k. Consider for example what could happen if this would be
> issued from userland when used with an OS.

+1 for consistency with arm/m68k. This applies more generally:
for example if there's any chance there might be a linux-user
implementation for xtensa then you want to use the softmmu-semi.h
helpers so the memory access will work in both setups.

m68k and ARM also both funnel semihosting through the interrupt/
exception mechanisms; I haven't figured out if there's a good
reason for that that would make it worth copying in xtensa :-)

>> +    SYS_exit = 1,

> I think these names may easily conflict with system defines, please
> use for example TARGET_SYS_exit etc.

Renaming's safe, but as it happens arm-semi.c has been
using SYS_EXIT &c with no problems, so I don't think it's
a big deal either way.

-- PMM



[Qemu-devel] [PATCH 0/8] cpu interrupt cleanup, v2

2011-05-04 Thread Richard Henderson
v1->v2
  Rebase vs HEAD (d2d979c)
  Cleanup whitespace errors.


r~

Richard Henderson (8):
  irq: Introduce CPU_INTERRUPT_TGT_* defines.
  irq: Introduce and use CPU_INTERRUPT_SSTEP_MASK.
  target-mips: Do not check CPU_INTERRUPT_TIMER.
  target-sparc: Do not check CPU_INTERRUPT_TIMER.
  irq: Remove CPU_INTERRUPT_TIMER.
  target-arm: Privatize CPU_INTERRUPT_FIQ.
  target-i386: Privatize some i386-specific interrupt names.
  irq: Privatize CPU_INTERRUPT_NMI.

 cpu-all.h   |   60 +-
 cpu-exec.c  |8 +-
 poison.h|   13 ++
 target-arm/cpu.h|4 +++
 target-cris/cpu.h   |3 ++
 target-i386/cpu.h   |9 +++
 target-microblaze/cpu.h |3 ++
 target-mips/exec.h  |4 ---
 8 files changed, 76 insertions(+), 28 deletions(-)

-- 
1.7.4.4




[Qemu-devel] [PATCH 1/8] irq: Introduce CPU_INTERRUPT_TGT_* defines.

2011-05-04 Thread Richard Henderson
These defines will be place-holders for cpu-specific functionality.
Generic code will, at the end of the patch series, no longer have to
concern itself about how SMI, NMI, etc should be handled.  Instead,
generic code will know only that the interrupt is internal or external.

Signed-off-by: Richard Henderson 
---
 cpu-all.h |   63 +---
 poison.h  |8 +++
 2 files changed, 59 insertions(+), 12 deletions(-)

diff --git a/cpu-all.h b/cpu-all.h
index 88126ea..dd9c230 100644
--- a/cpu-all.h
+++ b/cpu-all.h
@@ -786,18 +786,57 @@ void QEMU_NORETURN cpu_abort(CPUState *env, const char 
*fmt, ...)
 extern CPUState *first_cpu;
 extern CPUState *cpu_single_env;
 
-#define CPU_INTERRUPT_HARD   0x02 /* hardware interrupt pending */
-#define CPU_INTERRUPT_EXITTB 0x04 /* exit the current TB (use for x86 a20 
case) */
-#define CPU_INTERRUPT_TIMER  0x08 /* internal timer exception pending */
-#define CPU_INTERRUPT_FIQ0x10 /* Fast interrupt pending.  */
-#define CPU_INTERRUPT_HALT   0x20 /* CPU halt wanted */
-#define CPU_INTERRUPT_SMI0x40 /* (x86 only) SMI interrupt pending */
-#define CPU_INTERRUPT_DEBUG  0x80 /* Debug event occured.  */
-#define CPU_INTERRUPT_VIRQ   0x100 /* virtual interrupt pending.  */
-#define CPU_INTERRUPT_NMI0x200 /* NMI pending. */
-#define CPU_INTERRUPT_INIT   0x400 /* INIT pending. */
-#define CPU_INTERRUPT_SIPI   0x800 /* SIPI pending. */
-#define CPU_INTERRUPT_MCE0x1000 /* (x86 only) MCE pending. */
+/* Flags for use in ENV->INTERRUPT_PENDING.
+
+   The numbers assigned here are non-sequential in order to preserve
+   binary compatibility with the vmstate dump.  Bit 0 (0x0001) was
+   previously used for CPU_INTERRUPT_EXIT, and is cleared when loading
+   the vmstate dump.  */
+
+/* External hardware interrupt pending.  This is typically used for
+   interrupts from devices.  */
+#define CPU_INTERRUPT_HARD0x0002
+
+/* Exit the current TB.  This is typically used when some system-level device
+   makes some change to the memory mapping.  E.g. the a20 line change.  */
+#define CPU_INTERRUPT_EXITTB  0x0004
+
+/* Halt the CPU.  */
+#define CPU_INTERRUPT_HALT0x0020
+
+/* Debug event pending.  */
+#define CPU_INTERRUPT_DEBUG   0x0080
+
+/* Several target-specific external hardware interrupts.  Each target/cpu.h
+   should define proper names based on these defines.  */
+#define CPU_INTERRUPT_TGT_EXT_0   0x0008
+#define CPU_INTERRUPT_TGT_EXT_1   0x0010
+#define CPU_INTERRUPT_TGT_EXT_2   0x0040
+#define CPU_INTERRUPT_TGT_EXT_3   0x0200
+#define CPU_INTERRUPT_TGT_EXT_4   0x1000
+
+/* Several target-specific internal interrupts.  These differ from the
+   preceeding target-specific interrupts in that they are intended to
+   originate from within the cpu itself, typically in response to some
+   instruction being executed.  These, therefore, are not masked while
+   single-stepping within the debugger.  */
+#define CPU_INTERRUPT_TGT_INT_0   0x0100
+#define CPU_INTERRUPT_TGT_INT_1   0x0400
+#define CPU_INTERRUPT_TGT_INT_2   0x0800
+
+/* First unused bit: 0x2000.  */
+
+/* Temporary remapping from the generic names back to the previous
+   cpu-specific names.  These will be moved to target-foo/cpu.h next.  */
+#define CPU_INTERRUPT_TIMER   CPU_INTERRUPT_TGT_EXT_0
+#define CPU_INTERRUPT_FIQ CPU_INTERRUPT_TGT_EXT_1
+#define CPU_INTERRUPT_SMI CPU_INTERRUPT_TGT_EXT_2
+#define CPU_INTERRUPT_VIRQCPU_INTERRUPT_TGT_INT_0
+#define CPU_INTERRUPT_NMI CPU_INTERRUPT_TGT_EXT_3
+#define CPU_INTERRUPT_INITCPU_INTERRUPT_TGT_INT_1
+#define CPU_INTERRUPT_SIPICPU_INTERRUPT_TGT_INT_2
+#define CPU_INTERRUPT_MCE CPU_INTERRUPT_TGT_EXT_4
+
 
 #ifndef CONFIG_USER_ONLY
 typedef void (*CPUInterruptHandler)(CPUState *, int);
diff --git a/poison.h b/poison.h
index 93c75fa..8fa3ee6 100644
--- a/poison.h
+++ b/poison.h
@@ -46,6 +46,14 @@
 #pragma GCC poison CPU_INTERRUPT_DEBUG
 #pragma GCC poison CPU_INTERRUPT_VIRQ
 #pragma GCC poison CPU_INTERRUPT_NMI
+#pragma GCC poison CPU_INTERRUPT_TGT_EXT_0
+#pragma GCC poison CPU_INTERRUPT_TGT_EXT_1
+#pragma GCC poison CPU_INTERRUPT_TGT_EXT_2
+#pragma GCC poison CPU_INTERRUPT_TGT_EXT_3
+#pragma GCC poison CPU_INTERRUPT_TGT_EXT_4
+#pragma GCC poison CPU_INTERRUPT_TGT_INT_0
+#pragma GCC poison CPU_INTERRUPT_TGT_INT_1
+#pragma GCC poison CPU_INTERRUPT_TGT_INT_2
 
 #endif
 #endif
-- 
1.7.4.4




[Qemu-devel] [PATCH 6/8] target-arm: Privatize CPU_INTERRUPT_FIQ.

2011-05-04 Thread Richard Henderson
This interrupt name was only used by the ARM port.

Signed-off-by: Richard Henderson 
---
 cpu-all.h|1 -
 poison.h |1 -
 target-arm/cpu.h |4 
 3 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/cpu-all.h b/cpu-all.h
index a30943f..b1305db 100644
--- a/cpu-all.h
+++ b/cpu-all.h
@@ -828,7 +828,6 @@ extern CPUState *cpu_single_env;
 
 /* Temporary remapping from the generic names back to the previous
cpu-specific names.  These will be moved to target-foo/cpu.h next.  */
-#define CPU_INTERRUPT_FIQ CPU_INTERRUPT_TGT_EXT_1
 #define CPU_INTERRUPT_SMI CPU_INTERRUPT_TGT_EXT_2
 #define CPU_INTERRUPT_VIRQCPU_INTERRUPT_TGT_INT_0
 #define CPU_INTERRUPT_NMI CPU_INTERRUPT_TGT_EXT_3
diff --git a/poison.h b/poison.h
index 369d82d..787f8e9 100644
--- a/poison.h
+++ b/poison.h
@@ -39,7 +39,6 @@
 
 #pragma GCC poison CPU_INTERRUPT_HARD
 #pragma GCC poison CPU_INTERRUPT_EXITTB
-#pragma GCC poison CPU_INTERRUPT_FIQ
 #pragma GCC poison CPU_INTERRUPT_HALT
 #pragma GCC poison CPU_INTERRUPT_SMI
 #pragma GCC poison CPU_INTERRUPT_DEBUG
diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index d5af644..01f5b57 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -55,6 +55,10 @@
 #define ARMV7M_EXCP_PENDSV  14
 #define ARMV7M_EXCP_SYSTICK 15
 
+/* ARM-specific interrupt pending bits.  */
+#define CPU_INTERRUPT_FIQ   CPU_INTERRUPT_TGT_EXT_1
+
+
 typedef void ARMWriteCPFunc(void *opaque, int cp_info,
 int srcreg, int operand, uint32_t value);
 typedef uint32_t ARMReadCPFunc(void *opaque, int cp_info,
-- 
1.7.4.4




[Qemu-devel] [PATCH 7/8] target-i386: Privatize some i386-specific interrupt names.

2011-05-04 Thread Richard Henderson
SMI, VIRQ, INIT, SIPI, and MCE are all only used by the i386 port.

Signed-off-by: Richard Henderson 
---
 cpu-all.h |5 -
 poison.h  |2 --
 target-i386/cpu.h |8 
 3 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/cpu-all.h b/cpu-all.h
index b1305db..39dfa46 100644
--- a/cpu-all.h
+++ b/cpu-all.h
@@ -828,12 +828,7 @@ extern CPUState *cpu_single_env;
 
 /* Temporary remapping from the generic names back to the previous
cpu-specific names.  These will be moved to target-foo/cpu.h next.  */
-#define CPU_INTERRUPT_SMI CPU_INTERRUPT_TGT_EXT_2
-#define CPU_INTERRUPT_VIRQCPU_INTERRUPT_TGT_INT_0
 #define CPU_INTERRUPT_NMI CPU_INTERRUPT_TGT_EXT_3
-#define CPU_INTERRUPT_INITCPU_INTERRUPT_TGT_INT_1
-#define CPU_INTERRUPT_SIPICPU_INTERRUPT_TGT_INT_2
-#define CPU_INTERRUPT_MCE CPU_INTERRUPT_TGT_EXT_4
 
 /* The set of all bits that should be masked when single-stepping.  */
 #define CPU_INTERRUPT_SSTEP_MASK \
diff --git a/poison.h b/poison.h
index 787f8e9..4fcf46d 100644
--- a/poison.h
+++ b/poison.h
@@ -40,9 +40,7 @@
 #pragma GCC poison CPU_INTERRUPT_HARD
 #pragma GCC poison CPU_INTERRUPT_EXITTB
 #pragma GCC poison CPU_INTERRUPT_HALT
-#pragma GCC poison CPU_INTERRUPT_SMI
 #pragma GCC poison CPU_INTERRUPT_DEBUG
-#pragma GCC poison CPU_INTERRUPT_VIRQ
 #pragma GCC poison CPU_INTERRUPT_NMI
 #pragma GCC poison CPU_INTERRUPT_TGT_EXT_0
 #pragma GCC poison CPU_INTERRUPT_TGT_EXT_1
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index c7047d5..1fc421f 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -466,6 +466,14 @@
 #define EXCP_SYSCALL0x100 /* only happens in user only emulation
  for syscall instruction */
 
+/* i386-specific interrupt pending bits.  */
+#define CPU_INTERRUPT_SMI   CPU_INTERRUPT_TGT_EXT_2
+#define CPU_INTERRUPT_MCE   CPU_INTERRUPT_TGT_EXT_4
+#define CPU_INTERRUPT_VIRQ  CPU_INTERRUPT_TGT_INT_0
+#define CPU_INTERRUPT_INIT  CPU_INTERRUPT_TGT_INT_1
+#define CPU_INTERRUPT_SIPI  CPU_INTERRUPT_TGT_INT_2
+
+
 enum {
 CC_OP_DYNAMIC, /* must use dynamic code to get cc_op */
 CC_OP_EFLAGS,  /* all cc are explicitly computed, CC_SRC = flags */
-- 
1.7.4.4




[Qemu-devel] [PATCH 4/8] target-sparc: Do not check CPU_INTERRUPT_TIMER.

2011-05-04 Thread Richard Henderson
This bit is never set, therefore we should not read it either.

Signed-off-by: Richard Henderson 
---
 cpu-exec.c |3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/cpu-exec.c b/cpu-exec.c
index 5b42b25..6d43726 100644
--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -489,9 +489,6 @@ int cpu_exec(CPUState *env1)
 next_tb = 0;
 }
 }
-   } else if (interrupt_request & CPU_INTERRUPT_TIMER) {
-   //do_interrupt(0, 0, 0, 0, 0);
-   env->interrupt_request &= ~CPU_INTERRUPT_TIMER;
}
 #elif defined(TARGET_ARM)
 if (interrupt_request & CPU_INTERRUPT_FIQ
-- 
1.7.4.4




[Qemu-devel] [PATCH 3/8] target-mips: Do not check CPU_INTERRUPT_TIMER.

2011-05-04 Thread Richard Henderson
This bit is never set, therefore we should not read it either.

Signed-off-by: Richard Henderson 
---
 target-mips/exec.h |4 
 1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/target-mips/exec.h b/target-mips/exec.h
index b3c5a13..607edf1 100644
--- a/target-mips/exec.h
+++ b/target-mips/exec.h
@@ -29,10 +29,6 @@ static inline int cpu_has_work(CPUState *env)
 has_work = 1;
 }
 
-if (env->interrupt_request & CPU_INTERRUPT_TIMER) {
-has_work = 1;
-}
-
 return has_work;
 }
 
-- 
1.7.4.4




[Qemu-devel] [PATCH 5/8] irq: Remove CPU_INTERRUPT_TIMER.

2011-05-04 Thread Richard Henderson
It is no longer used anywhere.

Signed-off-by: Richard Henderson 
---
 cpu-all.h |1 -
 poison.h  |1 -
 2 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/cpu-all.h b/cpu-all.h
index bc0dad8..a30943f 100644
--- a/cpu-all.h
+++ b/cpu-all.h
@@ -828,7 +828,6 @@ extern CPUState *cpu_single_env;
 
 /* Temporary remapping from the generic names back to the previous
cpu-specific names.  These will be moved to target-foo/cpu.h next.  */
-#define CPU_INTERRUPT_TIMER   CPU_INTERRUPT_TGT_EXT_0
 #define CPU_INTERRUPT_FIQ CPU_INTERRUPT_TGT_EXT_1
 #define CPU_INTERRUPT_SMI CPU_INTERRUPT_TGT_EXT_2
 #define CPU_INTERRUPT_VIRQCPU_INTERRUPT_TGT_INT_0
diff --git a/poison.h b/poison.h
index 8fa3ee6..369d82d 100644
--- a/poison.h
+++ b/poison.h
@@ -39,7 +39,6 @@
 
 #pragma GCC poison CPU_INTERRUPT_HARD
 #pragma GCC poison CPU_INTERRUPT_EXITTB
-#pragma GCC poison CPU_INTERRUPT_TIMER
 #pragma GCC poison CPU_INTERRUPT_FIQ
 #pragma GCC poison CPU_INTERRUPT_HALT
 #pragma GCC poison CPU_INTERRUPT_SMI
-- 
1.7.4.4




  1   2   >