2016-11-28 16:28, Maxime Coquelin:
> On 11/24/2016 04:24 PM, Kavanagh, Mark B wrote:
> > DPDK v16.04 added support for vHost User TSO; as such, by default,
> > TSO is advertised to guest devices as an available feature during
> > feature negotiation with QEMU.
> > However, while the vHost user back
2014-12-12 15:50, Paolo Bonzini:
> On 12/12/2014 14:00, Carew, Alan wrote:
> > The problem is deterministic control of host CPU frequency and the DPDK
> > usage
> > model.
> > A hands-off power governor will scale based on workload, whether this is a
> > host
> > application or VM, so no problems
2014-12-09 18:35, Paolo Bonzini:
> Did you make any progress in Qemu/KVM community?
> We need to be sync'ed up with them to be sure we share the same goal.
> I want also to avoid using a solution which doesn't fit with their
> plan.
> Remember that we already had this probl
Alexander Graf wrote:
> Am 10.09.2010 um 18:08 schrieb "Edgar E. Iglesias"
:
> > On Fri, Sep 10, 2010 at 05:50:27PM +0200, Alexander Graf wrote:
> >> Thomas Monjalon wrote:
> >>> Alexander Graf wrote:
> >>>> Thomas Monjalon wrote:
>
Alexander Graf wrote:
> Thomas Monjalon wrote:
> > Alexander Graf wrote:
> >> Thomas Monjalon wrote:
> >>> From: till <608...@bugs.launchpad.net>
> >>>
> >>> According to FreeScale's 'Programming Environments Manual for 32-bi
Alexander Graf wrote:
> Thomas Monjalon wrote:
> > From: till <608...@bugs.launchpad.net>
> >
> > According to FreeScale's 'Programming Environments Manual for 32-bit
> > Implementations of the PowerPC Architecture' [MPCFPE32B, Rev.3, 9/2005],
Resetting the bit is necessary in order to bring the processor out of power
management since otherwise it goes to sleep right away in the exception
handler, i.e., it is impossible to leave PM-mode.
https://bugs.launchpad.net/qemu/+bug/608107
Signed-off-by: till <608...@bugs.launchpad.net>
** Changed in: qemu
Status: New => Confirmed
--
ppc fails to clear MSR_POW when incurring exception
https://bugs.launchpad.net/bugs/608107
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Status in QEMU: Confirmed
Bug description
My guest Linux/PPC cannot boot on my host x86 since this commit:
5d8a4f8f: tcg-i386: Merge 64-bit generation
This is the output:
zImage starting: loaded at 0x40 (sp: 0x004e5eb0)
inflate returned -3 msg: invalid literal/lengths set
--
Thomas
Alexander Graf wrote:
> Thomas, have you verified that it still boots a ppc64 guest?
No, but I don't see any specific link between ppc64 and this change.
This is the current (pseudo)code:
LE = 0
if ILE == 1
LE = 1
else
LE = 0
In all cases, LE will be overwritten after
From: Thomas Monjalon
Since commit 2ada0ed, "Return From Interrupt" is broken for PPC processors
because some interrupt specifics bits of SRR1 are copied to MSR.
SRR1 is a save of MSR during interrupt.
During RFI, MSR must be restored from SRR1.
But some bits of SRR1 are interrupt-sp
From: Thomas Monjalon
This line was a bit clear.
The next lines set or reset this bit (LE) depending of another bit (ILE).
So the first line is useless.
Signed-off-by: Thomas Monjalon
---
target-ppc/helper.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/target-ppc
Alexander Graf wrote:
> Thomas Monjalon wrote:
> > I'm running Linux for SBC834x in Qemu. The interrupt controller and board
> > definition are not yet published.
>
> Wow, I didn't know there were still new products based on e300.
Sorry, I was not clear. By "
Alexander Graf wrote:
> On 27.04.2010, at 17:31, Thomas Monjalon wrote:
> > Since commit 2ada0ed, "Return From Interrupt" is broken for PPC
> > processors because the upper bits (POW, TGPR, ILE) of MSR were not
> > cleared.
>
> May I ask for your test case or
Nikos Valavanis wrote:
> I am interested in adding a Renesas ARM Multicore Cortex A9 Development
> board to Qemu. Are there any FAQs on how to this?
There is a little doc on internals:
http://git.qemu.org/qemu.git/tree/qemu-tech.texi
But nothing about adding a board.
> Is anyone else working on a
From: Thomas Monjalon
1) Qemu is not only a PC emulator.
2) "image image" has already been changed to "disk image" in qemu-doc.texi
Signed-off-by: Thomas Monjalon
---
vl.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/vl.c b/vl.c
index a48
Blue Swirl wrote:
> On 4/27/10, Thomas Monjalon wrote:
> > The only improvement is in the fix for RFI/RFID.
> > Please Blue Swirl, could you test with Altivec ?
>
> Sorry, I don't have one.
Oops, sorry. I have "CCed" the author of the commit 2ada0ed. Bu
From: Thomas Monjalon
It appears in the code that the exception handling of 603e is the same as 603.
If there is addon like SRR1[KEY], it is handled without special case for it.
So it could be removed safely.
Signed-off-by: Thomas Monjalon
---
target-ppc/cpu.h|2 --
target-ppc
From: Thomas Monjalon
This function had been disabled from the beginning (see 9fddaa0).
cpu_reset() function is in target-ppc/helper.c
Signed-off-by: Thomas Monjalon
Acked-by: Alexander Graf
---
hw/ppc.c | 10 --
1 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/hw
From: Thomas Monjalon
The vectors are listed
- in the chapter 1.3.3.2 (Implementation-Specific Interrupt Model)
of the e300 datasheet [e300CORERM] and
- in the chapter 3.5.2 (PowerPC 603 Microprocessor Exception Model)
of the MPC603 datasheet.
As e300 inherits from MPC603
From: Thomas Monjalon
Since commit 2ada0ed, "Return From Interrupt" is broken for PPC processors
because the upper bits (POW, TGPR, ILE) of MSR were not cleared.
Below is a representation of MSR bits:
0 .. 12 13 14 15 16 .. 23 24.. 31
— POW TGPR
From: Thomas Monjalon
Mainly resending.
The only improvement is in the fix for RFI/RFID.
Please Blue Swirl, could you test with Altivec ?
---
Thomas Monjalon (5):
target-ppc: fix processor versions (PVR) for e300
target-ppc: fix interrupt vectors for MPC603 and e300
target-ppc
From: Thomas Monjalon
Reflect values from the table "Assigned PVR values" in [e300CORERM].
Values for MPC603 and G2 processors could need check/changes also.
The reference document (e300CORERM) which is used is:
"e300 Power Architecture Core Family Reference Manual",
From: Thomas Monjalon
Using GCC-4.2.4-1ubuntu4, there is a warning:
microblaze-dis.c:792: warning: unused variable 'fprintf'
Indeed, fprintf() is shadowed by a custom redefinition but is not used because
of FORTIFY_SOURCE option which replace calls to fprintf() by fprintf
Andreas Färber wrote:
> Am 23.04.2010 um 11:44 schrieb Thomas Monjalon:
> > It appears that the exception handling of 603e is the same as 603.
> > So it could be removed safely.
>
> Are you referring to some ppc manual or to the current code base?
I'm referring to the c
From: Thomas Monjalon
Since commit 2ada0ed, the PPC processors which have TGPR support
should be broken because the bit TGPR was not cleared.
After testing with e300, it seems that ILE should be cleared also.
Feedbacks welcomed, thanks.
Signed-off-by: Thomas Monjalon
---
target-ppc
From: Thomas Monjalon
It appears that the exception handling of 603e is the same as 603.
So it could be removed safely.
Signed-off-by: Thomas Monjalon
---
target-ppc/cpu.h|2 --
target-ppc/helper.c |3 ---
target-ppc/translate_init.c |5 +
3 files changed
Alexander Graf wrote:
> Thomas Monjalon wrote:
> > I'm slowly writing support for the WindRiver board SBC8349E.
> > For the moment, I send patches for things I'm sure.
>
> Nice. What kind of firmware does that use?
Hmm... I don't know. I don't have such
Alexander Graf wrote:
> > --- a/target-ppc/translate_init.c
> > +++ b/target-ppc/translate_init.c
> > @@ -2853,7 +2853,16 @@ static void init_excp_603 (CPUPPCState *env)
> > env->excp_vectors[POWERPC_EXCP_SMI] = 0x1400;
> > env->hreset_excp_prefix = 0xUL;
> > /* Hardwar
From: Thomas Monjalon
This function had been disabled from the beginning:
see 9fddaa0c0cabb610947146a79b4a9a38b0a216e5
cpu_reset() function is in target-ppc/helper.c
Signed-off-by: Thomas Monjalon
---
hw/ppc.c | 10 --
1 files changed, 0 insertions(+), 10 deletions(-)
diff --git a
From: Thomas Monjalon
Reflect values from the table "Assigned PVR values" in [e300CORERM].
Values for MPC603 and G2 processors could need check/changes also.
The reference document (e300CORERM) which is used is:
"e300 Power Architecture Core Family Reference Manual",
From: Thomas Monjalon
I'm working on e300.
It's still not working but these patches are some little steps in the right
direction.
My references:
ancestry: http://www.freescale.com/files/32bit/doc/data_sheet/MPC603.pdf
core:
http://www.freescale.com/files
From: Thomas Monjalon
The vectors are listed
- in the chapter 1.3.3.2 (Implementation-Specific Interrupt Model)
of the e300 datasheet [e300CORERM] and
- in the chapter 3.5.2 (PowerPC 603 Microprocessor Exception Model)
of the MPC603 datasheet.
As e300 inherits from MPC603
From: Thomas Monjalon
Using GCC-4.2.4-1ubuntu4, there is a warning:
microblaze-dis.c:792: warning: unused variable 'fprintf'
Indeed, fprintf() is shadowed by a custom redefinition but is not used because
of FORTIFY_SOURCE option which replace calls to fprintf() by fprintf_chk
Stefan Weil wrote:
> inst is unsigned long, so use %04lx instead of %04x.
>
> Signed-off-by: Stefan Weil
I've sent a patch
(http://lists.gnu.org/archive/html/qemu-devel/2010-04/msg00637.html)
which include this change and fix a bug, as explained by Paolo Bonzini:
http://lists.gnu.org/archive/htm
From: Thomas Monjalon
Using GCC-4.2.4-1ubuntu4, there were 3 warnings:
microblaze-dis.c:829: warning: format '%04x' expects type 'unsigned
int', but argument 4 has type 'long unsigned int'
microblaze-dis.c:962: warning: format '%04x' expe
Paolo Bonzini wrote:
> On 04/09/2010 12:22 AM, Thomas Monjalon wrote:
> > Using GCC-4.2.4-1ubuntu4, there were 3 warnings.
>
> The last two are correct, but what was the first error? If it was a
> shadowed declaration as it seems to be, the solution is to
> s/fprintf/fpr
From: Thomas Monjalon
Using GCC-4.2.4-1ubuntu4, there were 3 warnings.
Signed-off-by: Thomas Monjalon
---
microblaze-dis.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/microblaze-dis.c b/microblaze-dis.c
index b26572f..698ea7b 100644
--- a/microblaze-dis.c
From: Thomas Monjalon
There was a pointer cast warning on Ubuntu since _FORTIFY_SOURCE has been
reenabled.
_FORTIFY_SOURCE had been disabled by 4a24470497360d8b77568b83008d0e9d6eb0787d
and reenabled by 849583050d5f6f782718be8cb50688978973fbea.
Signed-off-by: Thomas Monjalon
---
hw/e1000.c
39 matches
Mail list logo
