On 4/28/20 4:45 AM, Colin Xu wrote:
Hi Paolo,
Would you please queue this one?
--
Best Regards,
Colin Xu
On Mon, 30 Mar 2020, Colin Xu wrote:
Looks good to me.
Reviewed-by: Colin Xu
On 2020-03-30 11:25, hang.y...@linux.intel.com wrote:
From: Hang Yuan
Add ROM and ROM device memory regi
Hi Paolo,
Would you please queue this one?
--
Best Regards,
Colin Xu
On Mon, 30 Mar 2020, Colin Xu wrote:
Looks good to me.
Reviewed-by: Colin Xu
On 2020-03-30 11:25, hang.y...@linux.intel.com wrote:
From: Hang Yuan
Add ROM and ROM device memory region support in HAX. Their memory regi
Looks good to me.
Reviewed-by: Colin Xu
On 2020-03-30 11:25, hang.y...@linux.intel.com wrote:
From: Hang Yuan
Add ROM and ROM device memory region support in HAX. Their memory region is
read only and write access will generate EPT violation. The violation will be
handled in the HAX kernel wi
From: Hang Yuan
Add ROM and ROM device memory region support in HAX. Their memory region is
read only and write access will generate EPT violation. The violation will be
handled in the HAX kernel with the following patch.
https://github.com/intel/haxm/commit/33ceea09a1655fca12c47f1e112b1d269357f
Hi TCG GIC developers,
There are a few gicv2 test failures when running over TCG that we don't
see when running over KVM. I don't believe these are regressions - I'm
pretty sure they've been failing since Andre first introduced the tests.
I'm just pointing them out now in case anybody would like
On Fri, 22 Mar 2019 at 16:40, Andrew Jones wrote:
> Hi TCG GIC developers,
>
> There are a few gicv2 test failures when running over TCG that we don't
> see when running over KVM. I don't believe these are regressions - I'm
> pretty sure they've been failing since Andre first introduced the tests.
On Fri, Jun 29, 2018 at 19:38:02 +0100, Mark Cave-Ayland wrote:
> On 29/06/18 19:18, Emilio G. Cota wrote:
> >I tried the last known good commit (as per your bisect) and get the same
> >results
> >as above.
> >
> >Is there any other way I could try reproducing this? Also, can you
> >reproduce with
On 29/06/18 19:18, Emilio G. Cota wrote:
On Fri, Jun 29, 2018 at 13:17:11 +0100, Mark Cave-Ayland wrote:
Whilst trying to debug an issue in OpenBIOS, I noticed that the gdbstub
single-step functionality was broken which I bisected down to this commit:
(snip)
commit b0c2d5213a14f8b9d44096ee879
On Fri, Jun 29, 2018 at 13:17:11 +0100, Mark Cave-Ayland wrote:
> Whilst trying to debug an issue in OpenBIOS, I noticed that the gdbstub
> single-step functionality was broken which I bisected down to this commit:
(snip)
> commit b0c2d5213a14f8b9d44096ee879a5d7f10fbc505
> Author: Emilio G. Cota
>
Hi all,
Whilst trying to debug an issue in OpenBIOS, I noticed that the gdbstub
single-step functionality was broken which I bisected down to this commit:
$ git bisect bad
b0c2d5213a14f8b9d44096ee879a5d7f10fbc505 is the first bad commit
commit b0c2d5213a14f8b9d44096ee879a5d7f10fbc505
Author:
On 11/07/2017 12:41 PM, Peter Maydell wrote:
> This is from https://bugs.launchpad.net/qemu/+bug/1701798, but
> that's quite a large thing, so here's the s390 specific part.
>
> On an ubuntu xenial install:
>
> $ apt install g++-5-s390x-linux-gnu
> $ cat hello.c
> #include
> int main(void) {
>
On 11/07/2017 01:00 PM, Thomas Huth wrote:
> If I've got the spec right, it's doing the same as
> RISBG (with subcode 0x55), but just does not set the condition code at
> the end, so this should be quite easy to implement?
That's right.
r~
On 11/07/2017 12:41 PM, Peter Maydell wrote:
> This is from https://bugs.launchpad.net/qemu/+bug/1701798, but
> that's quite a large thing, so here's the s390 specific part.
>
> On an ubuntu xenial install:
>
> $ apt install g++-5-s390x-linux-gnu
> $ cat hello.c
> #include
> int main(void) {
>
On 07.11.2017 12:41, Peter Maydell wrote:
> This is from https://bugs.launchpad.net/qemu/+bug/1701798, but
> that's quite a large thing, so here's the s390 specific part.
>
> On an ubuntu xenial install:
>
> $ apt install g++-5-s390x-linux-gnu
> $ cat hello.c
> #include
> int main(void) {
>
This is from https://bugs.launchpad.net/qemu/+bug/1701798, but
that's quite a large thing, so here's the s390 specific part.
On an ubuntu xenial install:
$ apt install g++-5-s390x-linux-gnu
$ cat hello.c
#include
int main(void) {
printf("hello world\n");
return 0;
}
$ s390x-linux-gnu-gcc
Peter Maydell writes:
> On 12 July 2017 at 12:39, Jaroslaw Pelczar wrote:
>> Problem manifests itself when we handle the following sequence:
>>
>> 1. 64-bit Secure EL3 returns to 32-bit Secure EL1
>> 2. 32-bit Secure EL1 performs SMC call to 64-bit Secure EL3
>> 3. 64-bit Secure EL3 performs re
On 12 July 2017 at 12:39, Jaroslaw Pelczar wrote:
> Problem manifests itself when we handle the following sequence:
>
> 1. 64-bit Secure EL3 returns to 32-bit Secure EL1
> 2. 32-bit Secure EL1 performs SMC call to 64-bit Secure EL3
> 3. 64-bit Secure EL3 performs return ERET to 32-bit Secure EL1]
Problem manifests itself when we handle the following sequence:
1. 64-bit Secure EL3 returns to 32-bit Secure EL1
2. 32-bit Secure EL1 performs SMC call to 64-bit Secure EL3
3. 64-bit Secure EL3 performs return ERET to 32-bit Secure EL1]
4. 32-bit Secure EL1 receives prefetch abort
If CPU's env->
On 2 June 2017 at 11:22, Anichang via Qemu-devel wrote:
> Attached patch since
>
> git://git.qemu.org/qemu.git 43771d5d92312504305c19abe29ec5bfabd55f01
> Running the sample board outputs:
>
> $ ./qemu-system-avr
> Unexpected error in object_property_add() at qom/object.c:940:
> qemu-system-avr: a
Hi all,
I just resurrected the target-avr patchset from Michael Rolnik. Following the
details:
commit f2bca179dbfc3f378b131ed619d07db946bae598
Merge: 43771d5 ed250c0
Author: Ani Chang
Date: Fri Jun 2 01:17:34 2017 +0200
target/avr: resurrected (see mailing list qemu-devel, Richard Henderson on
On 11/13/2016 10:39 AM, Alex Bennée wrote:
There does appear to be a problem with delivery of ISA interrupts for smp,
regardless whether mttcg is enabled or not, though PCI interrupts are working
fine. This appears in that both serial console and ps2 keyboard are
non-responsive, but one can ssh
Richard Henderson writes:
>> PID USER PR NIVIRTRES S P %CPU %MEM TIME+ COMMAND
>> 7817 rth 20 0 5304360 712404 R 3 94.4 9.1 2:45.21 qemu-system-alp
>> 7819 rth 20 0 5304360 712404 R 1 90.7 9.1 2:01.84 qemu-system-alp
>> 7818 rth 20 0 5304360 7
PID USER PR NIVIRTRES S P %CPU %MEM TIME+ COMMAND
7817 rth 20 0 5304360 712404 R 3 94.4 9.1 2:45.21 qemu-system-alp
7819 rth 20 0 5304360 712404 R 1 90.7 9.1 2:01.84 qemu-system-alp
7818 rth 20 0 5304360 712404 R 2 90.1 9.1 2:04.52 qemu-syste
On Mon, 2016-10-24 at 12:00 +1100, David Gibson wrote:
> Ben, does it look like the other extraneous changes in bd6fefe are at
> least correct, apart from being in the wrong patch?
It looks like part of my big rewrite of the exception stuff, so I'd
assume it's mostly correct minus a few bugs I fix
On Sat, Oct 22, 2016 at 09:22:45AM +0100, Mark Cave-Ayland wrote:
> On 21/10/16 23:02, Benjamin Herrenschmidt wrote:
>
> > On Fri, 2016-10-21 at 15:18 +0100, Mark Cave-Ayland wrote:
> >>
> >> bd6fefe71cec5a0c7d2be4ac96307f25db56abf9 is the first bad commit
> >> commit bd6fefe71cec5a0c7d2be4ac963
On 21/10/16 23:02, Benjamin Herrenschmidt wrote:
> On Fri, 2016-10-21 at 15:18 +0100, Mark Cave-Ayland wrote:
>>
>> bd6fefe71cec5a0c7d2be4ac96307f25db56abf9 is the first bad commit
>> commit bd6fefe71cec5a0c7d2be4ac96307f25db56abf9
>> Author: Benjamin Herrenschmidt
>> Date: Wed Jul 27 16:56:3
On Fri, 2016-10-21 at 15:18 +0100, Mark Cave-Ayland wrote:
>
> bd6fefe71cec5a0c7d2be4ac96307f25db56abf9 is the first bad commit
> commit bd6fefe71cec5a0c7d2be4ac96307f25db56abf9
> Author: Benjamin Herrenschmidt
> Date: Wed Jul 27 16:56:32 2016 +1000
>
> ppc: Make tlb_fill() use new excepti
Hi all,
I've just noticed the above regression in git master whilst trying to
debug something in openbios-ppc via QEMU's gdbstub. Reproduction here is
fairly easy using a debug build of OpenBIOS which I've uploaded to
https://www.ilande.co.uk/tmp/qemu/openbios-qemu.elf.nostrip for people
to test a
On Fri, Jul 29, 2016 at 08:04:04AM -0500, alar...@ddci.com wrote:
> David Gibson wrote on 07/29/2016 12:40:15
> AM:
>
> > From: David Gibson
> > To: alar...@ddci.com
> > Cc: qemu-devel@nongnu.org, qemu-...@nongnu.org, ag...@suse.de
> > Date: 07/29/2016 12:38 AM
> > Subject: Re: target-ppc: SPR_
David Gibson wrote on 07/29/2016 12:40:15
AM:
> From: David Gibson
> To: alar...@ddci.com
> Cc: qemu-devel@nongnu.org, qemu-...@nongnu.org, ag...@suse.de
> Date: 07/29/2016 12:38 AM
> Subject: Re: target-ppc: SPR_BOOKE_ESR not set on FP exceptions
>
> On Thu, Jul 28, 2016 at 06:32:27PM -0500,
On Thu, Jul 28, 2016 at 06:32:27PM -0500, alar...@ddci.com wrote:
> The target-ppc/excp_helper.c:powerpc_excp() case POWERPC_EXCP_FP fails
> to set "env->spr[SPR_BOOKE_ESR] = ESR_FP;". I can submit a patch for
> that,
Ok, please do.
> or anyone can add it, but I notice that in the other cases wh
The target-ppc/excp_helper.c:powerpc_excp() case POWERPC_EXCP_FP fails
to set "env->spr[SPR_BOOKE_ESR] = ESR_FP;". I can submit a patch for
that, or anyone can add it, but I notice that in the other cases where
SPR_BOOKE_ESR is set, the "msr" is ALSO set. Since the "msr" is used
to initialize SRR
On 27 November 2015 at 15:03, Tim Sander wrote:
> We are trying to call "inject_nmi" from a device on a x386 target.
> Unfortunatly it gets called with the wrong defines and the define
> TARGET_I386 is *not* defined. If we define TARGET_I386 for testing
> the code in the defines fails to compile.
Hi
We are trying to call "inject_nmi" from a device on a x386 target.
Unfortunatly it gets called with the wrong defines and the define
TARGET_I386 is *not* defined. If we define TARGET_I386 for testing
the code in the defines fails to compile.
Trying to fix this by including:
"qom/cpu.h" and "
On Wed, Sep 09, 2015 at 10:17:34AM +0200, Andrea Bolognani wrote:
> On Tue, 2015-09-08 at 16:47 +0100, Daniel P. Berrange wrote:
> > > Or we could just query everything that looks like a QEMU
> > > binary and then lookup the correct one for the guest based
> > > on the query results, couldn't we? A
On Tue, 2015-09-08 at 16:47 +0100, Daniel P. Berrange wrote:
> > Or we could just query everything that looks like a QEMU
> > binary and then lookup the correct one for the guest based
> > on the query results, couldn't we? Again, assuming such
> > interface even exists.
>
> I'd prefer libvirt to
On Tue, 2015-09-08 at 15:37 +0100, Daniel P. Berrange wrote:
> > at the moment, libvirt is using some ad-hoc logic to allow
> > i686 guests to run on qemu-system-x86_64 (by using the CPU
> > model qemu32); in all other cases, it's assumed that a $arch
> > guest needs qemu-system-$arch to run.
> >
On Tue, Sep 08, 2015 at 03:27:38PM +0200, Andrea Bolognani wrote:
> Hi,
>
> at the moment, libvirt is using some ad-hoc logic to allow
> i686 guests to run on qemu-system-x86_64 (by using the CPU
> model qemu32); in all other cases, it's assumed that a $arch
> guest needs qemu-system-$arch to run.
On Tue, Sep 08, 2015 at 05:34:42PM +0200, Andrea Bolognani wrote:
> On Tue, 2015-09-08 at 15:37 +0100, Daniel P. Berrange wrote:
> > > at the moment, libvirt is using some ad-hoc logic to allow
> > > i686 guests to run on qemu-system-x86_64 (by using the CPU
> > > model qemu32); in all other cases,
Hi,
at the moment, libvirt is using some ad-hoc logic to allow
i686 guests to run on qemu-system-x86_64 (by using the CPU
model qemu32); in all other cases, it's assumed that a $arch
guest needs qemu-system-$arch to run.
This is causing a problem right now with ppc64le guests
because, even though
On 02.07.15 06:44, Anton Blanchard wrote:
> We are setting SRR0 to the instruction before the one causing the
> unaligned exception. A quick testcase:
>
> . = 0x100
> .globl _start
> _start:
> /* Cause a 0x600 */
> li 3,0x1
> stwcx. 3,0,3
> 1:b 1b
>
> . = 0x600
I noticed that in function 'decode_opc()'(/target-mips/translate.c), there are
so many switch case sentence, why don't we change it to a table-driven
architecture? I've written a simple demo as following:
struct MIPSInstruction{
int op;
void (*op_func)(CPUMIPSState *, DisasContext
I noticed that in function 'decode_opc()'(/target-mips/translate.c), there are
so many switch case sentence, why don't we change it to a table-driven
architecture? I've written a simple demo as following:
struct MIPSInstruction{
int op;
void (*op_func)(CPUMIPSState *, DisasContext *
I noticed that in function 'decode_opc()'(/target-mips/translate.c),
there are so many switch case sentence, why don't we change it to a
table-driven architecture? I've written a simple demo as following:
struct MIPSInstruction{
int op;
void (*op_func)(CPUMIPSState *, DisasContext *);
We are setting SRR0 to the instruction before the one causing the
unaligned exception. A quick testcase:
. = 0x100
.globl _start
_start:
/* Cause a 0x600 */
li 3,0x1
stwcx. 3,0,3
1: b 1b
. = 0x600
1: b 1b
Built into something we can load as a B
On 07/04/2015 15:40, Andreas Färber wrote:
> Am 07.04.2015 um 15:29 schrieb Paolo Bonzini:
>> On 07/04/2015 15:24, Andreas Färber wrote:
> /* We hard-wire the BSP to the first CPU. */
> if (s->cpu_index == 0) {
> apic_designate_bsp(cpu->apic_state);
> }
>>> I k
On 07/04/15 16:29, Paolo Bonzini wrote:
On 07/04/2015 15:26, Denis V. Lunev wrote:
On 07/04/15 16:18, Paolo Bonzini wrote:
On 07/04/2015 13:57, Andreas Färber wrote:
If this is some issue with sync'ing state back and forth before
QEMU and
KVM then the real issue has not been explained.
Hm
Am 07.04.2015 um 15:44 schrieb Denis V. Lunev:
> On 07/04/15 16:29, Paolo Bonzini wrote:
>>
>>
>> On 07/04/2015 15:26, Denis V. Lunev wrote:
>>> On 07/04/15 16:18, Paolo Bonzini wrote:
On 07/04/2015 13:57, Andreas Färber wrote:
>>> If this is some issue with sync'ing state back a
Am 07.04.2015 um 15:29 schrieb Paolo Bonzini:
> On 07/04/2015 15:24, Andreas Färber wrote:
/* We hard-wire the BSP to the first CPU. */
if (s->cpu_index == 0) {
apic_designate_bsp(cpu->apic_state);
}
>> I know, that's what this patch is changing, and I am say
On 07/04/2015 15:24, Andreas Färber wrote:
>> > /* We hard-wire the BSP to the first CPU. */
>> > if (s->cpu_index == 0) {
>> > apic_designate_bsp(cpu->apic_state);
>> > }
> I know, that's what this patch is changing, and I am saying that by the
> same logic the CPU has no bus
On 07/04/2015 15:26, Denis V. Lunev wrote:
> On 07/04/15 16:18, Paolo Bonzini wrote:
>>
>>
>> On 07/04/2015 13:57, Andreas Färber wrote:
> If this is some issue with sync'ing state back and forth before
> QEMU and
> KVM then the real issue has not been explained.
>>> Hm, hw/intc/apic_
On 07/04/15 16:18, Paolo Bonzini wrote:
On 07/04/2015 13:57, Andreas Färber wrote:
If this is some issue with sync'ing state back and forth before QEMU and
KVM then the real issue has not been explained.
Hm, hw/intc/apic_common.c:apic_reset_common() has:
bsp = cpu_is_bsp(s->cpu);
s
Am 07.04.2015 um 15:14 schrieb Igor Mammedov:
> On Tue, 07 Apr 2015 13:57:34 +0200
> Andreas Färber wrote:
>
>> Am 07.04.2015 um 13:09 schrieb Andreas Färber:
>>> Am 07.04.2015 um 12:54 schrieb Paolo Bonzini:
On 07/04/2015 12:44, Andreas Färber wrote:
>>> It can change at runtime, though
On 07/04/2015 13:57, Andreas Färber wrote:
>> > If this is some issue with sync'ing state back and forth before QEMU and
>> > KVM then the real issue has not been explained.
> Hm, hw/intc/apic_common.c:apic_reset_common() has:
>
> bsp = cpu_is_bsp(s->cpu);
> s->apicbase = APIC_DEFAULT_AD
On Tue, 07 Apr 2015 13:57:34 +0200
Andreas Färber wrote:
> Am 07.04.2015 um 13:09 schrieb Andreas Färber:
> > Am 07.04.2015 um 12:54 schrieb Paolo Bonzini:
> >> On 07/04/2015 12:44, Andreas Färber wrote:
> > It can change at runtime, though, if you're using the KVM
> > in-kernel LAPIC.
>
Am 07.04.2015 um 13:09 schrieb Andreas Färber:
> Am 07.04.2015 um 12:54 schrieb Paolo Bonzini:
>> On 07/04/2015 12:44, Andreas Färber wrote:
> It can change at runtime, though, if you're using the KVM in-kernel LAPIC.
>>> Got a pointer? A quick git-grep doesn't show anything in hw/ or
>>> kvm-a
Am 07.04.2015 um 12:54 schrieb Paolo Bonzini:
> On 07/04/2015 12:44, Andreas Färber wrote:
It can change at runtime, though, if you're using the KVM in-kernel LAPIC.
>> Got a pointer? A quick git-grep doesn't show anything in hw/ or
>> kvm-all.c or target-i386/ assigning cpu_index, so it'll al
On 07/04/2015 12:44, Andreas Färber wrote:
>> > It can change at runtime, though, if you're using the KVM in-kernel LAPIC.
> Got a pointer? A quick git-grep doesn't show anything in hw/ or
> kvm-all.c or target-i386/ assigning cpu_index, so it'll always have the
> initial value.
Not cpu_index, s
Am 07.04.2015 um 12:34 schrieb Paolo Bonzini:
> On 07/04/2015 12:15, Andreas Färber wrote:
>> diff --git a/target-i386/cpu.c b/target-i386/cpu.c
>> index b2d1c95..03b33cf 100644
>> --- a/target-i386/cpu.c
>> +++ b/target-i386/cpu.c
>> @@ -2714,9 +2714,7 @@ static void x86_cpu_re
On 07/04/2015 12:15, Andreas Färber wrote:
>>> >> diff --git a/target-i386/cpu.c b/target-i386/cpu.c
>>> >> index b2d1c95..03b33cf 100644
>>> >> --- a/target-i386/cpu.c
>>> >> +++ b/target-i386/cpu.c
>>> >> @@ -2714,9 +2714,7 @@ static void x86_cpu_reset(CPUState *s)
>>> >>
>>> >> #if !defined
+Eduardo as target-i386 maintainer
Am 02.04.2015 um 14:34 schrieb Paolo Bonzini:
>
>
> On 02/04/2015 01:58, Nadav Amit wrote:
>> Since the BSP bit is writable on real hardware, during reset all the CPUs
>> which
>> were not chosen to be the BSP should have their BSP bit cleared. This fix is
>>
On 02/04/2015 01:58, Nadav Amit wrote:
> Since the BSP bit is writable on real hardware, during reset all the CPUs
> which
> were not chosen to be the BSP should have their BSP bit cleared. This fix is
> required for KVM to work correctly when it changes the BSP bit.
>
> An additional fix is re
Since the BSP bit is writable on real hardware, during reset all the CPUs which
were not chosen to be the BSP should have their BSP bit cleared. This fix is
required for KVM to work correctly when it changes the BSP bit.
An additional fix is required for QEMU tcg to allow software to change the BS
Coverity reports
Error: MISSING_BREAK:
target-tricore/translate.c:1648: unterminated_case: This case (value
"OPC1_32_B_JLA") is not terminated by a 'break' statement.
target-tricore/translate.c:1650: fallthrough: The above case falls through
to this one.
Here's the code:
case O
Hi Markus,
On 01/20/2015 09:23 AM, Markus Armbruster wrote:
Coverity[*] points out:
*** CID 1264337: Logically dead code (DEADCODE)
/target-tricore/translate.c: 348 in gen_mtcr()
342 #define E(ADDRESS, REG, FEATURE) A(ADDRESS, REG, FEATURE)
343 static inline void gen_mt
Coverity[*] points out:
*** CID 1264337: Logically dead code (DEADCODE)
/target-tricore/translate.c: 348 in gen_mtcr()
342 #define E(ADDRESS, REG, FEATURE) A(ADDRESS, REG, FEATURE)
343 static inline void gen_mtcr(CPUTriCoreState *env, DisasContext
*ctx, TCGv r1,
344
On Mon, May 19, 2014 at 1:56 PM, Mark Cave-Ayland
wrote:
> On 18/05/14 17:06, Olivier Danet wrote:
>
>> The problem may be related to the fact that the 32bits SPARCv8 and 64bits
>> SPARCv9 work in opposite directions !
>>
>> SparcV9 standard, page 360/399 :
>> The SPARC-V9 CWP register is incremen
On 18/05/14 17:06, Olivier Danet wrote:
The problem may be related to the fact that the 32bits SPARCv8 and 64bits
SPARCv9 work in opposite directions !
SparcV9 standard, page 360/399 :
The SPARC-V9 CWP register is incremented during a SAVE instruction and
decremented during
a RESTORE instruct
On 18/05/2014 14:48, Mark Cave-Ayland wrote:
> Hi all,
>
> I've been working on debugging a window-related OpenBIOS issue and noticed
> that the cwp register logic in QEMU appears to be backwards according to the
> SPARCv9 specification. From sections 6.3.6.1 and 6.3.6.2:
>
> "The SAVE instruct
Hi all,
I've been working on debugging a window-related OpenBIOS issue and
noticed that the cwp register logic in QEMU appears to be backwards
according to the SPARCv9 specification. From sections 6.3.6.1 and 6.3.6.2:
"The SAVE instruction allocates a new register window and saves the
caller
On Fri, Apr 25, 2014 at 05:38:08PM -0300, Eduardo Habkost wrote:
> Have you tested if your patch actually blocks savevm?
Yes, with -smp 2.
Can you please include the savevm.c patch in your queue?
TIA.
On Thu, Apr 24, 2014 at 06:32:42PM -0300, Marcelo Tosatti wrote:
> On Thu, Apr 24, 2014 at 04:21:59PM -0300, Eduardo Habkost wrote:
> > On Wed, Apr 23, 2014 at 06:04:45PM -0300, Marcelo Tosatti wrote:
> > >
> > > Invariant TSC documentation mentions that "invariant TSC will run at a
> > > constant
On Thu, Apr 24, 2014 at 04:21:59PM -0300, Eduardo Habkost wrote:
> On Wed, Apr 23, 2014 at 06:04:45PM -0300, Marcelo Tosatti wrote:
> >
> > Invariant TSC documentation mentions that "invariant TSC will run at a
> > constant rate in all ACPI P-, C-. and T-states".
> >
> > This is not the case if m
On Wed, Apr 23, 2014 at 06:04:45PM -0300, Marcelo Tosatti wrote:
>
> Invariant TSC documentation mentions that "invariant TSC will run at a
> constant rate in all ACPI P-, C-. and T-states".
>
> This is not the case if migration to a host with different TSC frequency
> is allowed, or if savevm i
Invariant TSC documentation mentions that "invariant TSC will run at a
constant rate in all ACPI P-, C-. and T-states".
This is not the case if migration to a host with different TSC frequency
is allowed, or if savevm is performed. So block migration/savevm.
Signed-off-by: Marcelo Tosatti
Ind
On Fri, 28 Mar 2014 18:25:02 +0800
Alexander Graf wrote:
>
>
> > Am 28.03.2014 um 16:16 schrieb Thomas Huth :
> >
> >
> > Hi all!
> >
> > There seems to be a problem with the emulation of the mtmsr instruction:
> > According to the PowerISA spec, chapter Book III-S, the mtmsr opcode
> > has
> Am 28.03.2014 um 16:16 schrieb Thomas Huth :
>
>
> Hi all!
>
> There seems to be a problem with the emulation of the mtmsr instruction:
> According to the PowerISA spec, chapter Book III-S, the mtmsr opcode
> has a so-called "L" field at bit position 15. Looking at the function
> gen_mtmsr()
Hi all!
There seems to be a problem with the emulation of the mtmsr instruction:
According to the PowerISA spec, chapter Book III-S, the mtmsr opcode
has a so-called "L" field at bit position 15. Looking at the function
gen_mtmsr() in target-ppc/translate.c, the bit is taken into account
since t
Il 18/03/2014 16:01, Peter Maydell ha scritto:
By whether the backend or the frontend has trivial
access to the value to be able to avoid doing bad
things if it's out of range. If either do, they can
do a translate-time check to avoid issues. If neither
does then we need the host CPU architecture
On 03/18/2014 08:01 AM, Peter Maydell wrote:
> Unless all our host architectures have undefined-result
> behaviour for variable shifts by out of range values
> then we can't make the TCG op semantics do that.
> (They probably can; the only counterexample I know
> of is the 8086, where the variable-
On 18 March 2014 14:56, Richard Henderson wrote:
> On 03/18/2014 07:47 AM, Peter Maydell wrote:
>> The interesting question is not immediate shifts
>> but variable ones. It's trivially easy for the frontend
>> to avoid passing out of range immediate values
>> and for the backend to screen them out
On 18 March 2014 14:47, Peter Maydell wrote:
> On 18 March 2014 14:39, Richard Henderson wrote:
>> On 03/18/2014 07:25 AM, Peter Maydell wrote:
>>> Why do you think this? tcg/README says out of
>>> range shifts are undefined behaviour. That means we
>>> mustn't execute them, and this code doesn't
On 03/18/2014 07:47 AM, Peter Maydell wrote:
> The interesting question is not immediate shifts
> but variable ones. It's trivially easy for the frontend
> to avoid passing out of range immediate values
> and for the backend to screen them out. This
> case is a variable shift TCG op.
Exactly how a
On 18 March 2014 14:39, Richard Henderson wrote:
> On 03/18/2014 07:25 AM, Peter Maydell wrote:
>> Why do you think this? tcg/README says out of
>> range shifts are undefined behaviour. That means we
>> mustn't execute them, and this code doesn't attempt
>> to branch around or otherwise avoid the
On 03/18/2014 07:25 AM, Peter Maydell wrote:
> Why do you think this? tcg/README says out of
> range shifts are undefined behaviour. That means we
> mustn't execute them, and this code doesn't attempt
> to branch around or otherwise avoid the shift by -1.
Bah. Stuff and nonsense. None of our bac
On 18 March 2014 14:20, Richard Henderson wrote:
> On 03/18/2014 05:33 AM, Peter Maydell wrote:
>> In this case the constant propagation code is smart
>> enough to figure out that tmp1 is always zero at op 85,
>> and therefore tmp3 is -1 at op 87. It then tries to use
>> the shift constant of -1 i
On 03/18/2014 05:33 AM, Peter Maydell wrote:
> 0x7fe9a5f
> 82 mov_i64 tmp1,rcx
> 83 mov_i64 tmp0,rax
> 84 movi_i64 tmp13,$0x1f
> 85 and_i64 tmp1,tmp1,tmp13
> 86 movi_i64 tmp13,$0x1
> 87 sub_i64 tmp3,tmp1,tmp13
> 88 shl_i64 tmp3,tmp0,tmp3
> 89 shl_i64 tmp0,tmp0,tmp1
> 90 ext3
If you run 'make check' under clang's -fsanitize=undefined, then
(among other things) the acpi test provokes these warnings:
/home/petmay01/linaro/qemu-from-laptop/qemu/tcg/optimize.c:833:44:
runtime error: shift exponent 18446744073709551615 is too large for
64-bit type 'tcg_target_ulong' (aka 'u
On 23 December 2013 08:13, Dennis Lan (dlan) wrote:
> On Mon, Dec 23, 2013 at 4:09 PM, Dennis Lan (dlan)
> wrote:
>>The problem is that there are still a few insn implementations
>> missing in matz's repo,
>> so I try to implement them myself[4]. I'm not familiar with qemu tcg,
>> so those pa
Hi Sarmad,
Am 24.04.2013 17:08, schrieb Andreas Färber:
> Am 24.04.2013 16:16, schrieb Sarmad Tanwir:
>>
>>> I am in process of adding a new target architecture named Tilera to
>>> qemu for emulation purpose. Until now, I have been working offline
>>> i.e. without submitting any patches or any c
On Mon, Dec 23, 2013 at 4:09 PM, Dennis Lan (dlan)
wrote:
> Hi Folks:
>I'm writing this letter mainly for help and suggestion.
>I'm using qemu-aarch64[1] from matz's repository, which actually is
> not official.
> with matz's repo, and trying to build a small gentoo rootfs, I
> encountered
Hi Folks:
I'm writing this letter mainly for help and suggestion.
I'm using qemu-aarch64[1] from matz's repository, which actually is
not official.
with matz's repo, and trying to build a small gentoo rootfs, I
encountered a problem with gcc-4.9.0 and if only commit[2] is
included, I have rep
On Mon, Jun 24, 2013 at 03:52:52PM +0800, Dongxue Zhang wrote:
> Hello everybody, i want to use mips target with smp support. When use
> command without smp, then the log stopped at "kernel panic", when -
> smp 2
> added, it stoppted at "NR_IRQS:256".
>
> I use the git qemu at 576156ffed72ab4feb
Hello everybody, i want to use mips target with smp support. When use
command without smp, then the log stopped at "kernel panic", when -smp 2
added, it stoppted at "NR_IRQS:256".
I use the git qemu at 576156ffed72ab4feb0b752979db86ff8759a2a1
qemu configed with "./configure --target-list=mips64el
On 04/30/2013 04:31:29 PM, Artyom Tarasenko wrote:
On Mon, Apr 29, 2013 at 7:43 AM, Rob Landley wrote:
> On 04/27/2013 03:00:06 PM, Artyom Tarasenko wrote:
>>
>> > For a lot of the 64-bit targets, actual 64 bit userspace support
is
>> > strangely lacking. For ppc64 they say to use ppc32, and I
On Mon, Apr 29, 2013 at 7:43 AM, Rob Landley wrote:
> On 04/27/2013 03:00:06 PM, Artyom Tarasenko wrote:
>>
>> > For a lot of the 64-bit targets, actual 64 bit userspace support is
>> > strangely lacking. For ppc64 they say to use ppc32, and I've been told
>> > that
>> > about sparc64 as well. I d
On 04/27/2013 03:00:06 PM, Artyom Tarasenko wrote:
> For a lot of the 64-bit targets, actual 64 bit userspace support is
> strangely lacking. For ppc64 they say to use ppc32, and I've been
told that
> about sparc64 as well. I don't know if this is an optimization or a
> requirement. I have a 3
On Wed, Apr 17, 2013 at 4:15 AM, Rob Landley wrote:
> On 04/14/2013 04:38:23 AM, Artyom Tarasenko wrote:
>>
>> On Sat, Apr 13, 2013 at 7:03 PM, Rob Landley wrote:
>> > On 03/26/2013 02:34:50 AM, Artyom Tarasenko wrote:
>> >>
>> >> On Tue, Mar 26, 2013 at 1:52 AM, Rob Landley wrote:
>> >> > Can t
Hi,
Am 24.04.2013 16:16, schrieb Sarmad Tanwir:
>
>> I am in process of adding a new target architecture named Tilera to
>> qemu for emulation purpose. Until now, I have been working offline
>> i.e. without submitting any patches or any comments from the community.
>>
>> I am almost done with
Hi guys,
>
>I am in process of adding a new target architecture named Tilera to qemu for
>emulation purpose. Until now, I have been working offline i.e. without
>submitting any patches or any comments from the community.
>
>I am almost done with definition of processor state and ISA translati
1 - 100 of 148 matches
Mail list logo
