Hi, All,
I'm using qemu-system-x86_64 in stable-2.1 and trying to use cpu pass-through
(-cpu host) to emulate my host processor architecture, which is Intel Xeon CPU
E5-2670 2.6GHz, 16 cores (2Sockets, 8Cores/Socket, 2Numa nodes).
But it seems that the virtual machine is stuck at somewhere, can
From: Johannes Schauer
A first try to introduce a generic setup for mapping environment variables to
command line options.
I'm afraid to code something for platforms I can't do runtime tests on, so this
is only for linux-user for now.
Signed-off-by: Johannes Schauer
---
linux-user/main.c |
Public bug reported:
Converting images with ftp or http as source could be done a lot faster.
The way it works now (qemu 1.7.50) is significantly slower than the
optimal way.
FTP - how it works now
1. Connect and login to ftp-server. Ask for size of file.
2. Get a chunk of data using rest+retr
3.
Public bug reported:
When using a non-US keyboard language through vnc and websockets, Alt-Gr
keyboard combinations do not work.
According to https://github.com/kanaka/noVNC/issues/406, this is a QEMU issue.
Tested with Qemu 2.2.1
** Affects: qemu
Importance: Undecided
Status: New
Alt-gr seems to be pressed in VM, but when pressing for example AltGr +
e, then the altgr-button is released just before e is pressed. When e is
released, altgr is pressed again.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https:/
When doing some more digging, it doesn't seem to be a QEMU issue as the
client releases altgr when pressing a key-combination.
** Changed in: qemu
Status: New => Invalid
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://
Hi Alex,
I am trying to pass through a PCI device to the guest to compare the
MSI interrupt latency with normal device pass through and pass through using
VFIO framework. I used the following script
for dev in $(ls /sys/bus/pci/devices/:06:00.0/iommu_group/devices); do
vendor=$(cat /sys/
Hi Alex,
> MSI routing updates aren't currently handled by pci-assign or
> vfio-pci (when using KVM acceleration), which means that trying to
> set interrupt SMP affinity in the guest has no effect unless MSI is
> completely disabled and re-enabled. This series fixes this for both
> device assignm
> > 45: 1 0 3377 11194 PCI-MSI-edge
> > FPGA_DEV> > RES: 14 20 21 3398 Rescheduling
> > interrupts---> Many RES Interrtups!!
>
> I don't know, but I'll fix the line wrap for anyone else that wants to
> have a look. The
hi,
I am currently using an old version of qemu which is still using bios from
bochs project. And I am wondering how to capture the output of those BX_INFO
and BX_DEBUG macros?
Thanks,
CJ
hi,
I am currently using an old version of qemu which is still using bios
from bochs project. And I am wondering how to capture the output of
those BX_INFO and BX_DEBUG macros?
Thanks,
CJ
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 Thu, 2007-04-12 at 10:49 -0500, Jason Wessel wrote:
> J. Mayer wrote:
> > On Wed, 2007-04-11 at 17:49 -0400, Rob Landley wrote:
> >
> >> qemu-system-ppc -M prep -nographic -kernel zImage-powerpc -append \
> >> "console=/dev/ttyS0"
> >
This patch adds a -pflash option to the Qemu command line.
This seems needed to instanciate parallel NOR flashes using the
pflash_cfi02 driver for embedded targets.
Please comment.
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
Index
40x. In an other hand the actual
microcontroller are more complex than most PowerPC 405.
All this is in my job queue !
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
targets: it may be needed not to register the I/O memory area in the
pckbd driver but let the caller do it.
Please take a look.
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
Index: vl.h
===
RCS file: /sources/qemu/qemu/vl.h,v
etter look to this patch then apply. There maybe
the same issue in the ppc64 strucutre ?
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
ile because I know several gcc 4.x bugs (crash during ISO C
compliant code and/or incorrect generated asm instructions), then I do
not consider gcc 4.x as usable for a production environment today. Maybe
this is the reason why Qemu runs OK on my machine but not on yours.
For your information, my testing system is an up-to-dat Gentoo Linux
distribution. My 32 bits test environment is another Gentoo distribution
in a chrooted environment, running on the same machine.
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
p_goto_tb1 and it
seems to work well here with the bash version I got.
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
?
I think there are busses and/or architectures where this is not
possible, you would only get a fault on the bus in such a case. So it
seems to me not to be easy to find a generic and appropriate way to fix
this behavior, don't you think ?
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
ould add no visible overhead (as calling a helper is
slow compared to direct micro-ops execution), then you would not need to
store those infos in the TB structure. This may even make the emulation
run faster has you won't fill the TB cache with multiple translation of
the same code each time t
c qruncom.c runcom.c
>test-i386-code16.S test-i386-muldiv.h
>test-i386-vm86.S test-i386.c test_path.c
>
> Log message:
> find -type f | xargs sed -i 's/[\t ]$//g' # on most files
Many thanks for generating hundreds of conflicts with a useless commit.
Don't know what's wrong in your expression but it did not what you think
it should (and you did not even check).
DON'T DO THIS KIND OF COMMIT AGAIN, PLEASE.
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
On Mon, 2007-09-17 at 10:27 +0200, Christian MICHON wrote:
> On 9/17/07, J. Mayer <[EMAIL PROTECTED]> wrote:
> > > Log message:
> > > find -type f | xargs sed -i 's/[\t ]$//g' # on most files
> >
> > Many thanks for generating hundreds o
issed ?
Regards.
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
ryone to use it.
Did anyone has done a long term comparison of CVS and git running on two copies
of the
same production repository and have made sure that any extraction at any
time of any data (ie, checkout in the present and any date in the past,
diffs, ...) of the two gives exactly the same result ? Please show me
such studies and I may reconsider my position... If not, you can always
use it, closing your eyes and praying for everything to be OK...
Regards.
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
On Mon, 2007-09-17 at 23:10 +0100, Paul Brook wrote:
> On Monday 17 September 2007, J. Mayer wrote:
> > It seems to me that there are many problems in linux-user/syscall.c
> > - problems for 64 bits targets:
> > it seems that do_syscall and child functions sh
On Tue, 2007-09-18 at 03:02 +0200, Alexander Graf wrote:
> Jocelyn Mayer wrote:
> > On Mon, 2007-09-17 at 12:02 +0200, Alexander Graf wrote:
> >
> >> J. Mayer wrote:
> >>
> >>> On Thu, 2007-09-13 at 17:27 +0200, Alexander Graf wrote:
>
Forwarded, as requested.
Forwarded Message
> From: Alexander Graf <[EMAIL PROTECTED]>
> To: J.Mayer <[EMAIL PROTECTED]>
> Subject: Re: [Qemu-devel] [PATCH] SVM support
> Date: Tue, 18 Sep 2007 13:51:26 +0200
>
> On Sep 18, 2007, at 12:09 PM, J. Ma
lated to 64 bits.
As I reported yesterday, there seem to be some confusions between
short/int and long types for all the targets I checked. There also seem
to be 64 bits issues, in addition...
I can see no mmap in IPC calls, but I noticed there is a problem for
32/64 bits compatibility with the shmat call. I guess this can be fixed
exactly in the same way mmap was fixed, forcing the requested address to
a known area when the caller does not specify any...
Regards.
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
On Tue, 2007-09-18 at 22:54 +0200, J. Mayer wrote:
> Forwarded, as requested.
>
> Forwarded Message
> > From: Alexander Graf <[EMAIL PROTECTED]>
> > To: J.Mayer <[EMAIL PROTECTED]>
> > Subject: Re: [Qemu-devel] [PATCH] SVM support
&g
tests to trigger specific bugs, just
launched command lines programs like bash, make, ... and used them. Then
other looks to the patch would be welcome !
Forwarded Message
> From: J. Mayer <[EMAIL PROTECTED]>
> Reply-To: qemu-devel@nongnu.org
> To: qemu-devel@nongn
.
One thing I really dislike is multiple statements on the same line. I
know this is only cosmetics (and that coding style discussion usually
have no end), but code like:
if () return -1;
can easily confuse any reader, imho, especially when the lines are long
then is to be avoided
Regards.
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
loss here won't be
> > sensible, but that may need to be proved.
>
> For some reason I thought the flags were also used in the hash lookup. This
> is
> not the case, so I withdraw my objection.
OK, then I feel like the flags size modification patch is acceptable.
If there is no objection (and if no one commits it before ;-)), I'm
ready to integrate it in the days to come.
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
correct for most (or all) cases. I did not
notice what the Power specification says that tlbre and tlbwe are
implementation dependent. I just compared IBM 440 and Freescale e500 TLB
models and, you're absolutelly right, they actually use different
implementation specific registers.
Thanks for reporting this !
I will start adding big warnings in my code until I can recode it in a
better way ;-)
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
On Wed, 2007-09-19 at 15:00 -0400, Stuart Anderson wrote:
> On Wed, 19 Sep 2007, J. Mayer wrote:
>
> > Then, the changes you've done, changing long arguments (which should be
> > target_long to be correct, you can take a look at the last patch I sent
> > on the list
On Wed, 2007-09-19 at 22:48 +0200, Aurelien Jarno wrote:
> Hi all,
Hi,
> The patch below moves likely()/unlikely() definitions to exec-all.h
> from target-alpha/cpu.h and target-ppc/cpu.h. This way they can be used
> on other targets.
Good idea, I will apply this.
Regards.
, 2007-09-19 at 10:07 +0100, Thiemo Seufer wrote:
> > J. Mayer wrote:
> > > Following my previous message, I did a patch that makes syscalls take
> > > target_long/target_ulong argument and return target_long value instead
> > > of long/unsigned long.
> > >
te a quick-and-dirty patch, but think that even more
> > old code could be removed.
> >
> > Stefan
> >
[...]
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
Index: hw/m48t59.c
===
RCS file: /sources/qemu/qem
On Mon, 2007-09-24 at 22:39 -0600, Thayne Harbaugh wrote:
> I've often wondered why there isn't a tswap_target_ulong(). Seems like
> using tswap32() is asking for trouble.
Isn't it tswapl ?
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
gt; was necessary before.
I've got a remark about this: why this has to be added to the Qemu
code ?
Imho, all is needed is an implementation of the -cpu option for
x86/x86_64 target. Then, an external tool (even a shell script) can be
used to determine what is the host CPU if you want to select the exact
same CPU to be emulated in Qemu. It seems to me that trying to do so is
out of the scope of Qemu code and just add unneeded complexity.
Regards.
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
odel, no more, no
less.
The only case it could be interresting, imho, is if you do not allow the
-cpu option in KVM case and force the cpu model instead using this
function. This behavior does not seem to be great idea to me.
Or maybe I missed something ?
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
er variable type (target_phys_addr_t ?) should be used
instead.
Regards.
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
example of a situation where
> the physical address space is much larger than ram.
I don't see why it would be useless to emulate huge amount of RAM on 32
bits hosts. If you try to register more than a few gigabytes of memory,
there are great chances that the host machine won't have
or if some rework will be needed.
Thanks by advance.
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
Index: linux-user/elfload.c
===
RCS file: /sources/qemu/qemu/linux-user/elfload.c,v
retrieving revision 1.48
diff -u -d -d -p
t; machines
> with >2G ram. Pretty much any machine with that much ram is also capable of
> running a 64-bit host OS.
You sure are right. But the point, imho, is: how to emulate all
available targets with all features, including 64 bits ones, on the mean
end-user PC ? This PC, as far as I know, is not a 64 bits machine. Most
end user will run in a full 64 bits environment in a few years, but they
don't now. And what we need is a way to provide features for what the
environment they use today
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
On Sun, 2007-09-30 at 04:15 +0200, Edgar E. Iglesias wrote:
> On Sun, Sep 30, 2007 at 03:39:15AM +0200, J. Mayer wrote:
> > Following what I've done in the syscalls emulation routines, it appeared
> > to me that there seems to be a lot of confusions between host and target
E__;
The fact the error mentions "__attribute__" and ALWAYS_INLINE make me
think the always_inline defintion is the suspect here
Regards.
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
On Sun, 2007-09-30 at 14:05 +0200, Andreas Färber wrote:
> Hi,
>
> Am 30.09.2007 um 13:45 schrieb J. Mayer:
>
> >> Anyone any idea what might've caused this build failure? I'm fairly
> >> certain I haven't messed with or updated the system heade
On Sun, 2007-09-30 at 10:15 +0300, Blue Swirl wrote:
> On 9/30/07, J. Mayer <[EMAIL PROTECTED]> wrote:
> > On Sat, 2007-09-29 at 23:43 +0100, Paul Brook wrote:
> > > > > Also note that changing variables from int to long have strictly no
> > > > > imp
On Sun, 2007-09-30 at 15:08 +0200, Andreas Färber wrote:
> Am 30.09.2007 um 14:17 schrieb J. Mayer:
>
> > On Sun, 2007-09-30 at 14:05 +0200, Andreas Färber wrote:
> >> Hi,
> >>
> >> Am 30.09.2007 um 13:45 schrieb J. Mayer:
> >>
> >>>&g
On Sun, 2007-09-30 at 16:28 +0200, Andreas Färber wrote:
> Am 30.09.2007 um 15:27 schrieb J. Mayer:
>
> > On Sun, 2007-09-30 at 15:08 +0200, Andreas Färber wrote:
> >> Am 30.09.2007 um 14:17 schrieb J. Mayer:
> >>> Would this new definition solve the compilat
On Sun, 2007-09-30 at 14:38 +0100, Thiemo Seufer wrote:
> J. Mayer wrote:
> > Following what I've done in the syscalls emulation routines, it appeared
> > to me that there seems to be a lot of confusions between host and target
> > long in the ELF loader.
>
> Bu
On Sun, 2007-09-30 at 17:05 +0200, Andreas Färber wrote:
> Am 30.09.2007 um 16:37 schrieb J. Mayer:
>
> >> If someone has a speedup idea for the __APPLE__ case, that could
> >> still be applied separately.
> >
> > I guess there are some already defined macro
On Sun, 2007-09-30 at 17:09 +0200, J. Mayer wrote:
> On Sun, 2007-09-30 at 14:38 +0100, Thiemo Seufer wrote:
> > J. Mayer wrote:
> > > Following what I've done in the syscalls emulation routines, it appeared
> > > to me that there seems to be a lot of confusions be
things but also breaks some features) and quick "minute" fixes.
The fact is that the online version of OHW is really outdated but my
working repository is not in a stable state and seems absolutelly not
usable as it is, then I'd prefer not to make it public for now...
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
ortant goal.
> >
> > The one doesn't exclude the other. That said, I regard the ability to
> > boot unaltered real-world firmare as an important test of the quality
> > of a system emulation.
>
> Maybe. The CPU probes for cacheline size, checks for errata #42 vs
> #45, reads debug registers, attempts to identify the bus speed by
> comparing I/O access times, tries to verify the system using a TPM and
> fails all cases. What can you do?
Most of the actual issues are in the chipset and it seems to me that the
less documented platforms are PC and Macs. A lot of other architectures
use quite well documented features and hardcoding some 'answers' can
often be sufficient to please the firmware. And even PowerPC Macs have a
great advantage: the firmware drivers are written in Forth, which is a
great help to understand what to do...
Then, yes, emulating PC chipsets is a real nightmare. But doing this for
a lot of other platforms, for which there is only a few or none open
source firmware or even OS running on, is really doable and is even a
requested feature by some hardware / software developpers.
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
in Qemu is an experimental feature that
should not be activated as default, as it seems not to be really usable
as it is now. I got no idea of what's going wrong in that code, I saw
nothing awfull at first sight (I only gave a quick look...) but it makes
Qemu unreliable and quite unusable, as far as
BIOS. But I feel more confortable keeping
all BIOS images together at the same place.
Please comment.
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
On Mon, 2007-10-01 at 04:35 +0100, Thiemo Seufer wrote:
> J. Mayer wrote:
> > On Sun, 2007-09-30 at 17:09 +0200, J. Mayer wrote:
> > > On Sun, 2007-09-30 at 14:38 +0100, Thiemo Seufer wrote:
> > > > J. Mayer wrote:
> > > > > Following what I&#
Forwarded Message
> From: J. Mayer <[EMAIL PROTECTED]>
> Reply-To: qemu-devel@nongnu.org
> To: qemu-devel@nongnu.org
> Subject: [Qemu-devel] RFC: BIOS filename option
> Date: Thu, 04 Oct 2007 05:11:55 +0200
>
> Hi,
>
> This is a proposal to all
On Thu, 2007-10-04 at 12:20 +0100, Thiemo Seufer wrote:
> J. Mayer wrote:
> [snip]
> > The thing I see is different is that the n32 ABI redefines elf_greg_t
> > and elf_caddr_t as 32 bits. Maybe I missed something but those types
> > seem not to be used by the ELF loader (o
On Thu, 2007-10-04 at 12:38 +0100, Thiemo Seufer wrote:
> J. Mayer wrote:
> > Hi,
> >
> > This is a proposal to allow the user to select a BIOS file name on the
> > command line. The goal is mainly to ease debug, for example when I want
> > to try to run a fir
needed fixes to avoid confusions between host_long and
target_long...
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
On Sun, 2007-10-07 at 17:38 +0300, Blue Swirl wrote:
> On 10/7/07, J. Mayer <[EMAIL PROTECTED]> wrote:
> > On Sun, 2007-10-07 at 15:45 +0300, Blue Swirl wrote:
> > > Hi,
> >
> > Hi,
> >
> > > This patch adds support for loading a 32 bit ELF file
On Sun, 2007-10-07 at 18:15 +0300, Blue Swirl wrote:
> On 10/7/07, J. Mayer <[EMAIL PROTECTED]> wrote:
> > On Sun, 2007-10-07 at 17:38 +0300, Blue Swirl wrote:
> > > On 10/7/07, J. Mayer <[EMAIL PROTECTED]> wrote:
> > > > On Sun, 2007-10-07 at 1
;
> Good point. I've updated the patch to use the personality field
> instead, for that I updated the personality stuff.
Well done !
I really like this new version as it is far less intrusive. And I guess
it can quite easily be used by other 64 bits targets.
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
s me what in the ISO C
specification, that I would have missed, explicitelly forbids this).
[...]
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
On Sun, 2007-10-07 at 18:40 -0400, Daniel Jacobowitz wrote:
> On Sun, Oct 07, 2007 at 11:45:51PM +0200, J. Mayer wrote:
> > I also took a look in C 99 specification and I saw no restriction on
> > writing:
> > do_this(a,
> > #ifdef _this_is_defined
> > b
lot of
examples of declarations/prototypes globally exported but only used
locally. Fixing this would make the code cleaner and, as a side effect,
would avoid a lot of waste of time recompiling useless stuff when doing
changes in headers.
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
case) this to avoid potential conflicts if the definition has to be
updated for any reason (ie support for new memory access modes,
emulation optimisation...)
Please comment.
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
Index:
cpu_list with a #if defined(cpu_list) that will have
to be suppressed once all target will implement this feature.
Please comment.
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
Index: vl.c
===
RCS file: /sources/qemu/qemu/
function and elf_check_arch to make other targets run as well.
Please comment.
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
Index: configure
===
RCS file: /sources/qemu/qemu/configure,v
retrieving revision 1.161
diff -u -d
On Wed, 2007-10-10 at 19:01 +0300, Blue Swirl wrote:
> On 10/10/07, J. Mayer <[EMAIL PROTECTED]> wrote:
> > Following the patches done for elfload32, it appeared to me that there
> > were still problems that would prevent 32 bits executables to run on 64
> > bit
On Wed, 2007-10-10 at 22:02 +0300, Blue Swirl wrote:
> On 10/10/07, Fabrice Bellard <[EMAIL PROTECTED]> wrote:
> > Thiemo Seufer wrote:
> > > Fabrice Bellard wrote:
> > >> J. Mayer wrote:
> > >>> Following the patches done for elfload32, it ap
ddress handling.
>
> Thanks.
Hi,
there are still a lot of problems hidden in syscalls.c and signal.c, as
you noticed.
Your patch seems OK to me and adding all those comments is imho really
great.
My only remark is a cosmetic one: I don't like too much hidding 'goto'
in macros...
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
On Thu, 2007-10-11 at 22:26 +0300, Blue Swirl wrote:
> On 10/10/07, Fabrice Bellard <[EMAIL PROTECTED]> wrote:
> > Thiemo Seufer wrote:
> > > Fabrice Bellard wrote:
> > >> J. Mayer wrote:
> > >>> Following the patches done for elfload32, it ap
On Thu, 2007-10-11 at 18:46 +0100, Thiemo Seufer wrote:
> 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:
> > > > > Here's a proposal t
Forwarded Message
> From: J. Mayer <[EMAIL PROTECTED]>
> Reply-To: qemu-devel@nongnu.org
> To: qemu-devel@nongnu.org
> Subject: [Qemu-devel] RFC: avoid #ifdef for target cpu list
> Date: Wed, 10 Oct 2007 07:14:22 +0200
>
> This tiny patch unifies th
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
, 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
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
> >
definitions, but having
this option for x86 too is welcome...
[...]
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
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
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 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
Then, your help and knowledge is welcome here !
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
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
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]>
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 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 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
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
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 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
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
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
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
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
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
1 - 100 of 1724 matches
Mail list logo
