us cases
One case that seems obviously not correct is that the
SENSE_INTERRUPT_STATUS should be treated as an invalid command when
there is no interrupt condition set.
The following patch implements the polling mode and the invalid
SENSE_INTERRUPT_STATUS case.
--
J. Mayer <[EMAIL PROTECTED]
On Sat, 2007-11-24 at 02:32 +0100, J. Mayer wrote:
> On Sat, 2007-11-24 at 00:52 +, Paul Brook wrote:
> > > > By your own admission, we can get away with not calculating the
> > > > high 32 bit of the register. If follows that the high bits are
> > &
is architecturally
correct and helps me debugging the 64 bits part; this is one of the
reasons why I first decided to do this way, the other one being the fact
it seems to lead to better code on my x86_64 host. When the 64 bits
emulation will be fully usable, I could imagine come back to "strict 32
bits" for the ppc-xxx target, as those target would become "not so
useful"...
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
if I get
convinced it would be better not to act this way. But this behavior is
sure not bugged, it exactly follows (or may say should exactly if well
implemented) the PowerPC specification.
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
s, they are to be dumped as 64 bits values. If you see bugs in
my code, please tell me I'll try to fix them (and I'll thank you for
this). But not doing weird things that are more buggy than the original
code !
But once again, the biggest problem is that you break my code without
any co
other solution would be to call another intermediary
function that would not be inlined to handle the recursive case.
The second solution may be better as it would keep the "fast" cases
inlined.
--
J. Mayer <[EMAIL PROTECTED]>
Never org
t actually solves the
problem.
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
Index: exec-all.h
===
RCS file: /sources/qemu/qemu/exec-all.h,v
retrieving revision 1.70
diff -u -d -d -p -r1.70 exec-all.h
--- exec-all.h 4 Nov 200
On Sat, 2007-11-17 at 12:57 +0100, andrzej zaborowski wrote:
> On 17/11/2007, J. Mayer <[EMAIL PROTECTED]> wrote:
> >
> > On Sat, 2007-11-17 at 11:44 +0100, andrzej zaborowski wrote:
> > > On 17/11/2007, J. Mayer <[EMAIL PROTECTED]> wrote:
> > >
On Sat, 2007-11-17 at 11:57 +0100, andrzej zaborowski wrote:
> On 17/11/2007, J. Mayer <[EMAIL PROTECTED]> wrote:
> >
> > On Fri, 2007-11-16 at 21:32 +0100, andrzej zaborowski wrote:
> > > On 16/11/2007, Jocelyn Mayer <[EMAIL PROTECTED]> wrote:
> > >
On Sat, 2007-11-17 at 11:44 +0100, andrzej zaborowski wrote:
> On 17/11/2007, J. Mayer <[EMAIL PROTECTED]> wrote:
> >
> > On Sat, 2007-11-17 at 11:14 +0100, andrzej zaborowski wrote:
> > > On 17/11/2007, J. Mayer <[EMAIL PROTECTED]> wrote:
> > >
functions declared as always_inline, this patch seems to allow the
PowerPC 64 target not to crash.
Please comment.
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
Index: exec-all.h
===
RCS file: /sources/qemu/qemu/exec-a
On Sat, 2007-11-17 at 11:14 +0100, andrzej zaborowski wrote:
> On 17/11/2007, J. Mayer <[EMAIL PROTECTED]> wrote:
> >
> > On Sat, 2007-11-17 at 09:53 +, Andrzej Zaborowski wrote:
> > > CVSROOT: /sources/qemu
> > > Module name: qemu
> > > C
ave any nasty side effect to do accesses in the reverse order ? Real
hardware do not ever seem to do this...
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
On Fri, 2007-11-16 at 18:58 -0800, Ben Pfaff wrote:
> "J. Mayer" <[EMAIL PROTECTED]> writes:
>
> > On Fri, 2007-11-16 at 21:32 +0100, andrzej zaborowski wrote:
> >> I think a line like
> >>
> >> #define inline __attribute__ (( always
ome cases lead to compiler warnings or errors. I already had
this kind of problems using the linux kernel headers which preciselly
uses this definitition.
But, once again, adding always_inline to functions does not completelly
solve the problem (please read the thread !) or at least does not solves
it with all gcc versions. The inline growth limits tweaking seems needed
too.
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
revious messages (titled "RFC: fix for random Qemu crashes).
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
On Fri, 2007-11-16 at 00:49 +0100, andrzej zaborowski wrote:
> Hi,
>
> On 16/11/2007, J. Mayer <[EMAIL PROTECTED]> wrote:
> > Some may have experienced of having some Qemu builds crashing,
> > apparently at random places, but in a reproducable way.
> > I foun
file.Unfortunatelly, there
is no way to disable those limits (I checked in the source code), then I
put them to an arbitrary high level. I also added the -funit-at-a-time
switch, as this kind of optimisation would not be relevant in op.o
context. The diff is attached in gcc_inline_limits.
On Sat, 2007-11-10 at 19:09 +0100, Aurelien Jarno wrote:
> J. Mayer a écrit :
> > On Sat, 2007-11-10 at 17:15 +0100, Aurelien Jarno wrote:
> >> J. Mayer a écrit :
> >>> On Sat, 2007-11-10 at 10:35 +0100, Aurelien Jarno wrote:
> >>>> J. Mayer a écri
On Sat, 2007-11-10 at 17:15 +0100, Aurelien Jarno wrote:
> J. Mayer a écrit :
> > On Sat, 2007-11-10 at 10:35 +0100, Aurelien Jarno wrote:
> >> J. Mayer a écrit :
> >>> On Thu, 2007-11-08 at 00:05 +0100, Aurelien Jarno wrote:
> >>>> On Tue, Nov
On Sat, 2007-11-10 at 10:35 +0100, Aurelien Jarno wrote:
> J. Mayer a écrit :
> > On Thu, 2007-11-08 at 00:05 +0100, Aurelien Jarno wrote:
> >> On Tue, Nov 06, 2007 at 09:01:13PM +0100, J. Mayer wrote:
> >>> On Sat, 2007-11-03 at 22:28 +0100, Aurelien Jarno wrote:
On Sat, 2007-11-10 at 00:43 +0100, andrzej zaborowski wrote:
> On 09/11/2007, J. Mayer <[EMAIL PROTECTED]> wrote:
> > What about this patch ? Is there any remark ? Is it to be applied ?
>
> Yes, I'm also in favour. Regarding the machines that boot off flash, I
>
On Thu, 2007-11-08 at 00:05 +0100, Aurelien Jarno wrote:
> On Tue, Nov 06, 2007 at 09:01:13PM +0100, J. Mayer wrote:
> >
> > On Sat, 2007-11-03 at 22:28 +0100, Aurelien Jarno wrote:
> > > On Sat, Nov 03, 2007 at 02:06:04PM -0400, Daniel Jacobowitz wrote:
> > >
; time. That's the same whether you have two binaries or one.
True.
> Duplicating the CPU definitions should also be fairly trivial. You're
> effectively already doing it when you build the separate ppc64 and ppc64h
> binaries. I find it hard to believe it would be hard to do
What about this patch ? Is there any remark ? Is it to be applied ?
Forwarded Message
> From: J. Mayer <[EMAIL PROTECTED]>
> Reply-To: qemu-devel@nongnu.org
> To: qemu-devel@nongnu.org
> Subject: Re: [Qemu-devel] multiple boot devices
> Date: Mon, 05 No
document, which describes the
whole hypervisor features is still a draft).
But it's a good idea, I may take a look of what it could provide.
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
et, it would bring
confusion for the user imho, and it does not seem easier to test.
> I can see why you want CPUs with and without hypervisor mode, I'm just not
> convinced it needs a separate qemu binary.
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
if the Apple SMU is said to do this before the CPU
boots (but there is no known way to check if it's true). Then, it will
make all PowerPC 64 emulated (but the 602) unusable as there'll be no
known OSS to manage them.
Removing the ppc64h target means, for me, removing any option to emulate
the hypervisor feature at any time (if removed) or removing the ability
to use the PowerPC 64 targets the way they are when booting on Apple G5
machines (if merged with the ppc64 target). None of those options seem
acceptable to me.
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
at it does not implement
precise FPU emulation, then there's no need to have specific code to
return a precise value (I mean target dependant) from the generic code,
imho.
[...]
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
On Sat, 2007-11-03 at 01:18 +, Thiemo Seufer wrote:
> J. Mayer wrote:
> [snip]
> > > > It restricts the letter to the ones historically allowed by Qemu, not to
> > > > anything specific to any architecture or hw platform. What I like in my
> > > > imp
On Sun, 2007-11-04 at 17:54 +, Paul Brook wrote:
> On Sunday 04 November 2007, J. Mayer wrote:
> > On Sun, 2007-11-04 at 12:17 +, Paul Brook wrote:
> > > > I have another solution: include all architecture specific files from
> > > > the main file.
>
dware specific stuffs from vl.c to hw subdirectory: for example,
the USB or display registration functions could go in a file in hw which
would avoid USBDevice or DisplayState to be defined globally.
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
y
of emulating BSD on Linux is the sysctl syscall, the trace facilites and
the ioctls. I guess we can forget the ioctls... Most of the other
syscalls mappings are quite like mapping one Linux port to another.
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
E_EXEC.
#ifdef TARGET_xxx should never occur in generic code and in that
specific case, it's the Sparc target code that has to be fixed...
> Maybe this issue should be documented in qemu-tech.texi, there are
> also frequently some questions about caches.
Yes, some documentation on such tricks can never hurt !
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
rPC 32 hosts.
Seems like it could be useful...
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
Index: host-utils.h
===
RCS file: /sources/qemu/qemu/host-utils.h,v
retrieving revision 1.3
diff -u -d -d -p -r1.3 host-utils.h
---
On Sat, 2007-11-03 at 19:16 -0600, Thayne Harbaugh wrote:
> On Sat, 2007-11-03 at 20:13 +0100, Fabrice Bellard wrote:
> > Thayne Harbaugh wrote:
> > > On Sat, 2007-11-03 at 13:52 +0100, J. Mayer wrote:
> > >> On Sat, 2007-11-03 at 01:21 +, Thiemo Seufer wrot
flavors (Net, Open and Free..).
Being able to add a BSD target sharing the same code would be a proof
the code is flexible and well organized; I guess large parts of the
Darwin user target could also be merged with a FreeBSD user target...
Just my few cents ideas, don't say it has to be implemented soon, just
think keeping those long-term goals in mind may help having a flexible
and clean implementation...
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
On Sat, 2007-11-03 at 01:18 +, Thiemo Seufer wrote:
> J. Mayer wrote:
> [snip]
> > > > It restricts the letter to the ones historically allowed by Qemu, not to
> > > > anything specific to any architecture or hw platform. What I like in my
> > > > imp
On Sat, 2007-11-03 at 01:01 +0100, andrzej zaborowski wrote:
> Hi,
>
> On 01/11/2007, J. Mayer <[EMAIL PROTECTED]> wrote:
> > On Thu, 2007-11-01 at 01:01 +0100, andrzej zaborowski wrote:
> > > On 31/10/2007, J. Mayer <[EMAIL PROTECTED]> wrote:
> > > &
On Fri, 2007-11-02 at 22:33 +0200, Blue Swirl wrote:
> On 11/2/07, Jocelyn Mayer <[EMAIL PROTECTED]> wrote:
> >
> > On Fri, 2007-11-02 at 17:18 +0200, Blue Swirl wrote:
> > > On 11/2/07, J. Mayer <[EMAIL PROTECTED]> wrote:
> > > >
> >
enable some
optimisations at run-time. Or applications like mplayer... But I don't
see why init should ever have any usage of knowing the CPU features...
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
would certainly be useful.
Seems like I made a mistake for program exception generation while
fixing floating-point ones, I'm sorry. Your patch is incorrect but the
one attached should fix the problem. Could you please check it in your
case ?
--
J. Mayer <[EMAIL
On Thu, 2007-11-01 at 23:13 +0100, J. Mayer wrote:
> On Thu, 2007-11-01 at 21:53 +0200, Blue Swirl wrote:
> > On 11/1/07, Blue Swirl <[EMAIL PROTECTED]> wrote:
> > > On 10/29/07, Jocelyn Mayer <[EMAIL PROTECTED]> wrote:
> > > > CVSROOT:
;Ware) related hacks.
Those functions will never go in m48t59.h as they are not related with
m48t59. Apple machine don't have such a device (even if Qemu pretend it
has, this is to be removed in the days to come) but need those functions
to pass arguments to the firmware. What I needed to do (and that what I
did commit) is make those routines independant from m48t59 so I can
remove this device from ppc_chrp.c and ppc_oldworld.c and use the real
Mac nvram instead (but ppc_prep.c still uses m48t59...).
Whatever, I'll try to fix the sparc64 case as I broke it (if I found the
code ;-) ).
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
On Thu, 2007-11-01 at 01:01 +0100, andrzej zaborowski wrote:
> Hi,
>
> On 31/10/2007, J. Mayer <[EMAIL PROTECTED]> wrote:
> >
> > On Wed, 2007-10-31 at 11:22 +0100, J. Mayer wrote:
> > > On Wed, 2007-10-31 at 11:01 +0100, andrzej zaborowski wrote:
>
On Wed, 2007-10-31 at 11:22 +0100, J. Mayer wrote:
> On Wed, 2007-10-31 at 11:01 +0100, andrzej zaborowski wrote:
> > On 31/10/2007, J. Mayer <[EMAIL PROTECTED]> wrote:
> > >
> > > On Wed, 2007-10-31 at 03:35 +0100, andrzej zaborowski wrote:
> > > >
On Wed, 2007-10-31 at 11:01 +0100, andrzej zaborowski wrote:
> On 31/10/2007, J. Mayer <[EMAIL PROTECTED]> wrote:
> >
> > On Wed, 2007-10-31 at 03:35 +0100, andrzej zaborowski wrote:
> > > Hi,
> > >
> > > On 31/10/2007, J. Mayer <[EMAIL PROTECTE
On Wed, 2007-10-31 at 03:35 +0100, andrzej zaborowski wrote:
> Hi,
>
> On 31/10/2007, J. Mayer <[EMAIL PROTECTED]> wrote:
> >
> > On Wed, 2007-10-31 at 01:54 +, Andrzej Zaborowski wrote:
> > > CVSROOT: /sources/qemu
> > > Module name: qemu
&
boot devices are possible to select (see the
BOOTCHARS definition), which clearly shows the patch is not consistent.
Furthermore, the patch breaks the coding style in some files (at least
the ones I checked), which is weird.
Seems _very_ strange to see it commited, then.
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
On Mon, 2007-10-29 at 22:33 +0100, Aurelien Jarno wrote:
> On Mon, Oct 29, 2007 at 10:21:26PM +0100, J. Mayer wrote:
> >
> > On Mon, 2007-10-29 at 22:12 +0100, Aurelien Jarno wrote:
> > > > CVSROOT:/sources/qemu
> > > > Module name:qemu
> >
Could you please try replacing the 0x3FF mask with 0x7FF ? As the
exponent is supposed to be 11 bits, my patch is obviously still buggy...
I noticed there was a bug somewhere, but was not convinced it was in the
FPU emulation... Now ...
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
les.
make may rebuild a lot of things (or everything) when some headers are
modified because some headers (like vl.h) are included almost in every
source file.
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
boot scripts, I will commit and publish a new version soon (I
hope !).
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
On Sun, 2007-10-28 at 00:53 +0200, J. Mayer wrote:
> Following the previous discussions about host-utils implementations,
> here's a patch with the following changes:
> - move mulu64 and muls64 definitions from exec.h to host-utils.h, for
> consistency
> - include host-util
ation method
ctpop8 is used by the PowerPC target, I added ctpop16 for consistency
- change the Alpha and the PowerPC targets to use those helpers
Please comment.
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
Index: exec-all.h
=
2 ^ 29 random
numbers to achieve this test (and checked that the repartition was OK).
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
On Sat, 2007-10-27 at 16:01 +0300, Blue Swirl wrote:
> On 10/27/07, J. Mayer <[EMAIL PROTECTED]> wrote:
> > I also got optimized versions of bit population count which could also
> > be shared:
> > static always_inline int ctpop32 (uint32_t val)
> > {
> >
On Sat, 2007-10-27 at 12:19 +0100, Thiemo Seufer wrote:
> J. Mayer wrote:
> > The latest patches in clo makes gcc 3.4.6 fail to build the mips64
> > targets on my amd64 host (looks like an register allocation clash in the
> > optimizer code).
>
> Your versi
On Wed, 2007-10-24 at 18:37 +0100, Thiemo Seufer wrote:
> J. Mayer wrote:
> >
> > On Wed, 2007-10-24 at 12:20 +0200, Fabrice Bellard wrote:
> > > I strongly suggest to reuse my code which was in target-i386/helper.c
> > > revision 1.80 which was far easi
he PowerPC part, there could be a local int boot_device
variable that would be initialized to the first argument of the table.
And this would not change the NVRAM initialisation API: if this API need
to support more than one boot device in the future, it will have to be
completelly reworked (for other reasons too), then I would suggest to be
conservative and do not change this API at all.
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
= _do_cntlzw(~T0);
RETURN();
}
void op_clz (void)
{
-int n;
-
-if (T0 == 0) {
-T0 = 32;
-} else {
-for (n = 0; n < 32; n++) {
-if (T0 & (1 << 31))
-break;
-T0 <<= 1;
- }
-T0 = n;
-}
+T0 = _do_cntlzw(T0);
RETURN();
}
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
t; > CVSWeb URLs:
> > http://cvs.savannah.gnu.org/viewcvs/qemu/host-utils.c?cvsroot=qemu&r1=1.1&r2=1.2
> >
> >
> >
> >
>
>
>
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
e a problem in your gcc package.
I used this little program to check the builtin presence and found no
version from gcc 3.4.4 to gcc 4.2.2 without __builtin_clz implemented:
int a = 123456;
int main (void)
{
int b;
b = __builtin_clz(a);
return b;
}
Compiled with gcc- -O2 -Wall -W -o /tmp/clz /tmp/ckz.c
[...]
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
On Tue, 2007-10-23 at 23:59 +0200, Aurelien Jarno wrote:
> J. Mayer a écrit :
> > On Tue, 2007-10-23 at 12:47 +0100, Thiemo Seufer wrote:
> >> J. Mayer wrote:
> >>> On Tue, 2007-10-23 at 00:05 +0200, Aurelien Jarno wrote:
> >>>> J. Mayer a écri
On Tue, 2007-10-23 at 12:47 +0100, Thiemo Seufer wrote:
> J. Mayer wrote:
> >
> > On Tue, 2007-10-23 at 00:05 +0200, Aurelien Jarno wrote:
> > > J. Mayer a écrit :
> > > > On Mon, 2007-10-22 at 18:28 +0200, Aurelien Jarno wrote:
> > > >> On Mo
Hi,
Sorry for the delay...
On Fri, 2007-10-19 at 12:57 -0500, Milton Miller wrote:
> On Oct 18, 2007, at 6:46 PM, J. Mayer wrote:
> > On Thu, 2007-10-18 at 19:12 -0500, Rob Landley wrote:
[...]
> Rob was complaining he needed arch ppc to boot prep qemu but
> kernel_headers
; be still available from the vnc server (which can't be disabled).
Then, it seems better to me to be add an option to disable the VNC
server. Why should we have a graphical output when we want to emulate
boards that don't have any kind of graphical devices ?
[...]
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
On Mon, 2007-10-22 at 09:43 +0200, Oliver Falk wrote:
> On 10/21/2007 01:06 PM, J. Mayer wrote:
> > On Sun, 2007-10-21 at 05:43 -0500, Rob Landley wrote:
> >> On Saturday 20 October 2007 3:56:12 am J. Mayer wrote:
> >>> On Fri, 2007-10-19 at 19:49 -0500, Rob Land
On Tue, 2007-10-23 at 00:05 +0200, Aurelien Jarno wrote:
> J. Mayer a écrit :
> > On Mon, 2007-10-22 at 18:28 +0200, Aurelien Jarno wrote:
> >> On Mon, Oct 22, 2007 at 09:36:07AM +0200, J. Mayer wrote:
> >>> Hi all,
> >>>
> >>> I've been
On Mon, 2007-10-22 at 18:28 +0200, Aurelien Jarno wrote:
> On Mon, Oct 22, 2007 at 09:36:07AM +0200, J. Mayer wrote:
> > Hi all,
> >
> > I've been investigating more about PreP kernel boot using Qemu and I
> > achieved to boot 2.4.35, 2.6.12 and 2.6.22 kernels u
pc/boot/images/zImage.prep
Hope this helps.
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
On Sun, 2007-10-21 at 12:24 +0200, J. Mayer wrote:
> On Sun, 2007-10-21 at 04:55 -0500, Rob Landley wrote:
> > On Saturday 20 October 2007 3:50:52 am J. Mayer wrote:
[...]
> > > And you can get the list of all CPUs emulated by Qemu with the '-cpu ?'
> > > swi
On Sun, 2007-10-21 at 05:43 -0500, Rob Landley wrote:
> On Saturday 20 October 2007 3:56:12 am J. Mayer wrote:
> > On Fri, 2007-10-19 at 19:49 -0500, Rob Landley wrote:
> > > On Sunday 14 October 2007 5:14:27 am J. Mayer wrote:
> > > > On Sun, 2007-10-14 at
On Sun, 2007-10-21 at 04:55 -0500, Rob Landley wrote:
> On Saturday 20 October 2007 3:50:52 am J. Mayer wrote:
> > Sleep mode is currently implemented only for a few CPUs. I should add
> > all the currently emulated cores. For this, I would have to emulate the
> > HID re
> The bug could also be trigger with sprintf(), so this is not directly
> related to I/O. It happens when printing an integer followed by a float,
> even when the two are printed in two different calls to printf().
OK, thanks. I'll do test with this program. It seems that floats are OK
when running 2.4 kernels, it maybe a difference in recent glibc. I'll
try to investigate more about it.
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
On Sat, 2007-10-20 at 13:49 +0100, Thiemo Seufer wrote:
> J. Mayer wrote:
> >
> > On Fri, 2007-10-19 at 19:49 -0500, Rob Landley wrote:
> > > On Sunday 14 October 2007 5:14:27 am J. Mayer wrote:
> > > > On Sun, 2007-10-14 at 11:19 +0200, Oliver Falk wrote:
&
ew
seconds after reaching this point, the same way it does when I can see
it waiting for the user login.
So I will apply the patch. I also added PCI network devices but still
haven't validated them.
>
> Index: hw/i8259.c
> ====
On Fri, 2007-10-19 at 19:49 -0500, Rob Landley wrote:
> On Sunday 14 October 2007 5:14:27 am J. Mayer wrote:
> > On Sun, 2007-10-14 at 11:19 +0200, Oliver Falk wrote:
> > > Hi list!
> >
> > Hi you !
> >
> > > Just wanted to know how far the progress on
e on my web pages, to have a more
readable PowerPC reference document. Of course, any information about
missing PVRs or PowerPC implementation in welcome !
You can also take a look at the file target-ppc/STATUS file to figure
out all cores emulation working in Qemu.
And you can get the list of all CPUs emulated by Qemu with the '-cpu ?'
switch.
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
obsolete and the heathrow target does not reflect any
real machine. But this is to be solved, for sure.
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
On Wed, 2007-10-17 at 22:06 +0300, Blue Swirl wrote:
> On 10/17/07, Jocelyn Mayer <[EMAIL PROTECTED]> wrote:
> > On Wed, 2007-10-17 at 14:51 +0100, Thiemo Seufer wrote:
> > > J. Mayer wrote:
> > > > I failed to run Mips target test image on my amd64 machine a
r the last cc pointer each
time we finish translating an insn. I'll think about this solution,
which really seems feasible to me.
> Trying to generate prefetch aborts at runtime sounds too hairy for my liking.
It might be really tricky and is likely to be bugged, I agree.
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
really know if some Mips target specific constraints would
make one of the other solution prefered, I'd better let the specialist
choose !
The good news is that, once this issue is fixed, the Mips test images
run with the reverse-endian softmmu patch applied.
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
on may be to link the TB with a
special other TB that would just raise this exception and would be
unlink once the exception has been treated. Or maybe the solution would
just be to stop the translation knowing that the exception will be
raised when trying to translate the first instruction in the next page.
There still may be specific problems for instructions spanning 2 pages,
using those solutions...
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
be void for most targets, except for Sparc where
the phys_pc needs to be adjusted after the translation of each target
instruction.
and maybe more, if needed.
This structure could also contain target specific information. To
address the problem of segment limit check reported by Fabrice Bellard,
we could for example add the address of the next segment limit for x86
target and add a target specific check at the start of the ldx_code_p
function. But I don't know much about segmentation "subtilities" on x86,
then this idea may not be appropriate to solve this problem.
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
On Mon, 2007-10-15 at 19:02 +0300, Blue Swirl wrote:
> On 10/15/07, J. Mayer <[EMAIL PROTECTED]> wrote:
> > On Sun, 2007-10-14 at 15:59 +0300, Blue Swirl wrote:
> > > On 10/14/07, J. Mayer <[EMAIL PROTECTED]> wrote:
> > > > Here's an updated version
On Sun, 2007-10-14 at 15:59 +0300, Blue Swirl wrote:
> On 10/14/07, J. Mayer <[EMAIL PROTECTED]> wrote:
> > Here's an updated version of the patch against current CVS.
> > This patches provides reverse-endian, little-endian and big-endian
> > memory accessors, av
On Mon, 2007-10-15 at 03:30 +0100, Paul Brook wrote:
> On Sunday 14 October 2007, J. Mayer wrote:
> > Here's an updated version of the code fetch optimisation patch against
> > current CVS.
> > As a remainder, this patch avoid use of softmmu helpers to fetch the
> >
On Sun, 2007-10-14 at 14:22 +0100, Thiemo Seufer wrote:
> J. Mayer wrote:
> [snip]
> > > > Here's a new version. The only change is that, for consistency, I did
> > > > add the big-endian and little-endian accessors that were documented in
> > > > cp
Following the discussion initiated last week about Qemu build
dependencies, I do propose to include the included patch (or the one
that was previously proposed that was very close to this one).
Please tell about any objection or improvments suggestions.
--
J. Mayer <[EMAIL PROTECTED]>
pages, when the target CPU uses a variable-length instructions encoding.
For pure RISC, the code fetch is done using raw access routines.
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
Index: cpu-all.h
===
RCS file: /sources/qe
Then, your help and knowledge is welcome here !
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
On Sun, 2007-10-14 at 11:19 +0300, Blue Swirl wrote:
> On 10/14/07, J. Mayer <[EMAIL PROTECTED]> wrote:
> > On Sat, 2007-10-13 at 16:17 +0200, J. Mayer wrote:
> > > On Sat, 2007-10-13 at 16:07 +0300, Blue Swirl wrote:
> > > > On 10/13/07, J. Mayer <[EMAIL PR
On Fri, 2007-10-12 at 09:01 +0200, J. Mayer wrote:
> On Thu, 2007-10-11 at 14:09 +0200, J. Mayer wrote:
> > On Wed, 2007-10-10 at 07:06 +0200, J. Mayer wrote:
> > > On Wed, 2007-10-10 at 01:12 +0100, Thiemo Seufer wrote:
> > > > J. Mayer wrote:
> >
On Sat, 2007-10-13 at 20:07 +0100, Thiemo Seufer wrote:
> J. Mayer wrote:
> [snip]
> > > My idea of always using the ldx_code_p function is that we may have the
> > > occasion to make it more cleaver and make the slow case handle code
> > > execution in mmi
definitions, but having
this option for x86 too is welcome...
[...]
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
On Sat, 2007-10-13 at 10:11 +0300, Blue Swirl wrote:
> On 10/13/07, J. Mayer <[EMAIL PROTECTED]> wrote:
> > Forwarded Message
> > > From: Jocelyn Mayer <[EMAIL PROTECTED]>
> > > Reply-To: [EMAIL PROTECTED], qemu-devel@nongnu.org
> >
, 2007-10-12 at 18:21 +0300, Blue Swirl wrote:
> > On 10/12/07, J. Mayer <[EMAIL PROTECTED]> wrote:
> > > Here's a small patch that allow an optimisation for code fetch, at least
> > > for RISC CPU targets, as suggested by Fabrice Bellard.
> > > The main idea
C and SH4.
I don't actually know if the optimsation would bring a sensible speed
gain or if it will be absolutelly marginal.
Please comment.
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
Index: cpu-exec.c
===
RCS file: /s
lly stripped, which means the debug symbols are not present
anymore.
A way to get the debug symbol is to fetch the source and recompile it...
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
1 - 100 of 233 matches
Mail list logo
