Hi,
The CR3 caching was never implemented in QEMU and is obsoleted by
NPT/EPT. This patch removes the unused references to it from
target-i386/kvm.c.
Cheers,
Jes
commit 5ed16687929511d015dd3542c4359cabe170401a
Author: Jes Sorensen
Date: Fri Feb 19 07:39:56 2010 +0100
Remove all referenc
---
target-arm/cpu.h |1 +
target-arm/helper.c|3 +++
target-arm/translate.c | 17 +++--
3 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index 4a1c53f..8751402 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -
Signed-off-by: Richard Henderson
---
tcg/sparc/tcg-target.c |5 +
tcg/sparc/tcg-target.h |2 ++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/tcg/sparc/tcg-target.c b/tcg/sparc/tcg-target.c
index 1ea474d..891b8c4 100644
--- a/tcg/sparc/tcg-target.c
+++ b/tcg/sparc/tcg
Changes since v1:
* Add comments for all optional instructions that aren't implemented
on each architecture, as requested.
* Rebase vs master.
r~
Richard Henderson (7):
tcg-sparc: Implement neg.
tcg-sparc: Implement not.
tcg: Optional target implementation of ANDC.
tcg: Optional ta
Signed-off-by: Richard Henderson
---
tcg/arm/tcg-target.h| 14 ++
tcg/i386/tcg-target.h | 12 +++-
tcg/mips/tcg-target.h |4 +++-
tcg/ppc/tcg-target.h| 10 +-
tcg/ppc64/tcg-target.h | 25 ++---
tcg/s390/tcg-target.h | 30
Signed-off-by: Richard Henderson
---
tcg/sparc/tcg-target.c |6 ++
tcg/sparc/tcg-target.h |2 ++
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/tcg/sparc/tcg-target.c b/tcg/sparc/tcg-target.c
index 55c74af..1ea474d 100644
--- a/tcg/sparc/tcg-target.c
+++ b/tcg/sparc/tc
Previously ANDC was always implemented by tcg-op.h with
an explicit NOT opcode. Allow a target implementation.
Signed-off-by: Richard Henderson
---
tcg/tcg-op.h | 11 +++
tcg/tcg-opc.h |6 ++
2 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/tcg/tcg-op.h b/tcg/t
The fallback implementation of "ret = 0 - arg1" isn't ideal,
first because of the extra tcg op to load the zero, and second
because we fail to handle zero as %g0 for arg1 of the sub.
Signed-off-by: Richard Henderson
---
tcg/sparc/tcg-target.c | 13 +
tcg/sparc/tcg-target.h |5 +
Previously ORC was always implemented by tcg-op.h with
an explicit NOT opcode. Allow a target implementation.
Signed-off-by: Richard Henderson
---
tcg/tcg-op.h | 11 +++
tcg/tcg-opc.h |6 ++
2 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/tcg/tcg-op.h b/tcg/tc
The fallback implementation of "ret = arg1 ^ -1" isn't ideal
because of the extra tcg op to load the minus one.
Signed-off-by: Richard Henderson
---
tcg/sparc/tcg-target.c |6 ++
tcg/sparc/tcg-target.h |2 ++
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/tcg/sparc/tc
I took a stub at documenting CMD and FLUSH request types in virtio
block. Christoph, could you look over this please?
I note that the interface seems full of warts to me,
this might be a first step to cleaning them.
One issue I struggled with especially is how type
field mixes bits and non-bit v
On 02/18/2010 02:24 PM, Luiz Capitulino wrote:
Vendors might want to add their own extensions to QMP, as JSON itself
(and several other protocols) allow this someway, I think QMP should
allow too.
We just have to choose a naming convention that is guaranteed not to
clash with any future new comm
On Thu, Feb 18, 2010 at 4:41 PM, Dmitry Antipov wrote:
> Hello all,
>
> is there any support for 64-bit MMIO?
No, though there has been some discussion about it before which you
can find in the archives. 64 bit MMIO would be useful for Sparc32,
Sparc64 and Alpha.
> I'm trying to emulate 16750-li
Thanks, applied both.
On Thu, Feb 18, 2010 at 10:25 PM, Paolo Bonzini wrote:
> Since b567b38 (target-arm: remove T0 and T1, 2009-10-16) the only global
> register that is used is AREG0, so the complexity of hostregs_helper.h
> is unused. Use regular assignments and a compiler optimization barrie
Since b567b38 (target-arm: remove T0 and T1, 2009-10-16) the only global
register that is used is AREG0, so the complexity of hostregs_helper.h
is unused. Use regular assignments and a compiler optimization barrier.
Signed-off-by: Paolo Bonzini
---
v1->v2: added QEMU prefix to BUILD_BUG_
Signed-off-by: Paolo Bonzini
---
target-m68k/exec.h |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/target-m68k/exec.h b/target-m68k/exec.h
index 1267bb6..ece9aa0 100644
--- a/target-m68k/exec.h
+++ b/target-m68k/exec.h
@@ -20,10 +20,6 @@
#include "dyngen-exec.h"
r
Vendors might want to add their own extensions to QMP, as JSON itself
(and several other protocols) allow this someway, I think QMP should
allow too.
We just have to choose a naming convention that is guaranteed not to
clash with any future new commands, arguments, parameters and event
names.
Si
Thanks, applied.
On Mon, Feb 15, 2010 at 6:17 PM, Stefan Weil wrote:
> When compiled with CONFIG_DEBUG_TCG, this code looks
> for missing, duplicate and wrong entries in the
> op definitions.
>
> Errors will raise an assertion at program start
> (all checks are done in the initial phase).
>
> The
On Thu, Feb 11, 2010 at 1:26 AM, Paolo Bonzini wrote:
> Since b567b38 (target-arm: remove T0 and T1, 2009-10-16) the only global
> register that is used is AREG0, so the complexity of hostregs_helper.h
> is unused. Use regular assignments and a compiler optimization barrier.
In file included fro
I have not seen a follow up. I believe the comments regarding whitespace
and coding style have been addressed.
Thanks,
David Ahern
On 02/10/2010 06:27 PM, David Ahern wrote:
> v1 -> v2 coding style changes
>
> Add a tty close callback. Right now if a guest device that is connected
> to a tty-b
2010/2/18 Taimoor Mirza :
> Hi all,
>
> I've been getting following errors while building qemu 0.11.1 and 0.12.2 on
> my Redhat machine.
>
> block/curl.c:80: error: syntax error before "curl_socket_t"
> block/curl.c:82: warning: function declaration isn't a prototype
> block/curl.c: In function `cu
Hi all,
I've been getting following errors while building qemu 0.11.1 and 0.12.2 on my
Redhat machine.
block/curl.c:80: error: syntax error before "curl_socket_t"
block/curl.c:82: warning: function declaration isn't a prototype
block/curl.c: In function `curl_sock_cb':
block/curl.c:84: error: `
Hello all,
is there any support for 64-bit MMIO?
I'm trying to emulate 16750-like UART by adopting current 16550A emulation.
The problem is that my (MIPS) hardware is 64-bit, and native software
issues 64-bit load/stores (LD/SD) to talk with all hardware registers,
which are all 64-bit too (for
2010/2/18 Rob Landley :
> On Thursday 18 February 2010 05:21:16 Artyom Tarasenko wrote:
>> 2010/2/17 Rob Landley :
>> qemu-sparc can decently run debian-40r8: gcc and all the other stuff
>> seem to work.
>>
>> Most versions of the NetBSD boot. Some require the original OBP
>> though. The only known
2010/2/18 Rob Landley :
> On Thursday 18 February 2010 05:38:01 Artyom Tarasenko wrote:
>> 2010/2/17 Blue Swirl :
>> > On Wed, Feb 17, 2010 at 8:55 PM, Rob Landley wrote:
>> >> On Wednesday 17 February 2010 09:45:48 Paolo Bonzini wrote:
>> >>> On 02/17/2010 10:24 AM, Artyom Tarasenko wrote:
>> >>>
See individual patches for details.
Change the way the internal qemu signal, used for communication between
iothread and vcpus, is handled.
Block and consume it with sigtimedwait on the outer vcpu loop, which
allows more precise timing control.
Change from standard signal (SIGUSR1) to real-time one, so multiple
signals are not col
With SIG_IPI blocked vcpu loop exit notification happens via -EAGAIN
from KVM_RUN.
Signed-off-by: Marcelo Tosatti
Index: qemu/kvm-all.c
===
--- qemu.orig/kvm-all.c
+++ qemu/kvm-all.c
@@ -753,11 +753,13 @@ int kvm_cpu_exec(CPUState *
In KVM mode the global mutex is released when vcpus are executing,
which means acquiring the fairness mutex is not required.
Also for KVM there is one thread per vcpu, so tcg_has_work is meaningless.
Add a new qemu_wait_io_event_common function to hold common code
between TCG/KVM.
Signed-off-by:
On Thursday 18 February 2010 05:38:01 Artyom Tarasenko wrote:
> 2010/2/17 Blue Swirl :
> > On Wed, Feb 17, 2010 at 8:55 PM, Rob Landley wrote:
> >> On Wednesday 17 February 2010 09:45:48 Paolo Bonzini wrote:
> >>> On 02/17/2010 10:24 AM, Artyom Tarasenko wrote:
> >>> >> I've also got a bunch of "s
On Thursday 18 February 2010 05:21:16 Artyom Tarasenko wrote:
> 2010/2/17 Rob Landley :
> qemu-sparc can decently run debian-40r8: gcc and all the other stuff
> seem to work.
>
> Most versions of the NetBSD boot. Some require the original OBP
> though. The only known to me version which definetely
On Wednesday 17 February 2010 14:46:15 Blue Swirl wrote:
> > Alas the image has no hint how to reproduce it. Doesn't say what
> > toolchain it was built with, what kernel .config was used, and so on.
> > (The arm one at least had /proc/config.gz...)
> >
> > Well, actually if you "mount -t proc pr
Kevin Wolf wrote:
> Implement some more refcount block related checks
>
> Signed-off-by: Kevin Wolf
Reviewed-by: Juan Quintela
Kevin Wolf wrote:
> +/* Find the refcount block for the given cluster */
> +refcount_table_index = cluster_index >> (s->cluster_bits -
> REFCOUNT_SHIFT);
> +if (refcount_table_index >= s->refcount_table_size) {
> +refcount_block_offset = 0;
> +} else {
> +refcount
2010/2/17 Blue Swirl :
> On Wed, Feb 17, 2010 at 8:55 PM, Rob Landley wrote:
>> On Wednesday 17 February 2010 09:45:48 Paolo Bonzini wrote:
>>> On 02/17/2010 10:24 AM, Artyom Tarasenko wrote:
>>> >> I've also got a bunch of "sort of working, but not well enough
>>> >> to run builds natively under"
2010/2/17 Rob Landley :
> On Wednesday 17 February 2010 09:45:48 Paolo Bonzini wrote:
>> On 02/17/2010 10:24 AM, Artyom Tarasenko wrote:
>> >> I've also got a bunch of "sort of working, but not well enough
>> >> to run builds natively under" targets on top of that (arm big
>> >> endian, sh4, sparc.
Kevin Wolf wrote:
> When the refcount table grows, it doesn't only grow by one entry but reserves
> some space for future refcount blocks. The algorithm to calculate the number
> of
> entries stays the same with the fixes, so factor it out before replacing the
> rest.
>
> Signed-off-by: Kevin Wol
On 18.02.2010, at 06:57, OHMURA Kei wrote:
>> "We think"? I mean - yes, I think so too. But have you actually measured
>> it?
>> How much improvement are we talking here?
>> Is it still faster when a bswap is involved?
> Thanks for pointing out.
> I will post the data for
38 matches
Mail list logo
