Filip Navara wrote:
> Hi Ryan & others,
>
> now I have been holding a SMBIOS patch on my hard disk for way to long it
> seems. I used a different approach from yours, so I decided to publish it
> for review or further ideas. What I did was to modify the bochs bios to
> produce the SMBIOS tables an
Thayne Harbaugh wrote:
> I believe Paul Brook did the original patch for arm eabi TLS. The patch
> has bounced around for a bit but hasn't been applied. We've been using
> this patch for a while and have tweaked it to be a bit more correct as
> far as code organization.
>
> Please let me know wh
Paul Brook wrote:
- It would be good to limit the changes in the CPU emulation code to
handle the TLS. For example, on MIPS, the TLS register must not be
stored in the CPU state. Same for ARM.
I disagree. The TLS register is part of the CPU state. On many machines
(including ARMv6 CPUs) it's a
Laurent Vivier wrote:
> This patch enhances the "-drive ,cache=off" mode with IDE drive emulation
> by removing the buffer used in the IDE emulation.
> ---
> block.c | 10 +++
> block.h |2
> block_int.h |1
> cpu-all.h |1
> exec.c | 19 ++
> hw/ide.c| 1
Laurent Vivier wrote:
> This patch adds a new parameter to "-drive"
>
> Using "cache=off" with "-drive" will open the disk image file using
> "O_DIRECT".
>
> By default, "cache" is set to "on" to keep original behavior of qemu.
>
> example:
>
> "-drive file=my_disk.qcow2,cache=off"
> ---
> blo
Blue Swirl wrote:
> CVSROOT: /cvsroot/qemu
> Module name: qemu
> Changes by: Blue Swirl 08/01/01 16:57:19
>
> Modified files:
> . : cpu-all.h exec.c
>
> Log message:
>Support for registering address space only for some access widths
>
> CVSWeb URLs:
> http:/
Blue Swirl wrote:
On 1/3/08, Paul Brook <[EMAIL PROTECTED]> wrote:
On Wednesday 02 January 2008, Blue Swirl wrote:
On 1/2/08, Paul Brook <[EMAIL PROTECTED]> wrote:
Also the opaque parameter may need to be different for each function,
it just didn't matter for the unassigned memory case.
Do yo
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard08/01/06 17:10:54
Modified files:
. : Changelog VERSION
Log message:
version change
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/Changelog?cvsroot=qemu&r1=1.15
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard08/01/06 17:21:49
Modified files:
. : qemu-img.c vl.c
linux-user : main.c
Log message:
copyright update
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard08/01/06 18:27:12
Modified files:
. : Makefile
Log message:
update binary distribution
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile?cvsroot=qemu&r1=1.13
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard08/01/06 18:27:58
Modified files:
. : configure Makefile.target
Log message:
fixed ppc64abi32 executable name
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/configure
Can you explain why you use the block layer (block-raw-posix.c) to send
your low level SCSI commands ? I suggest to remove your patches to
block-raw-posix.c and to implement all the SCSI passthough in
scsi-generic.c.
Regards,
Fabrice.
Laurent Vivier wrote:
> This patch allows to use SCSI passthr
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard08/01/06 18:53:07
Modified files:
. : block-raw-posix.c
Log message:
restore original values for ai.aio_threads and ai.aio_num
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs
Hi,
QEMU version 0.9.1 is out ! You can get it from:
http://bellard.org/qemu/download.html .
Fabrice.
Alexander Graf wrote:
This patch is mostly a cleanup of Michael Matz's patch with the ideas
that came last time included.
I must say I don't like such patches because they are likely to break
with every new GCC version.
Moreover, I will commit in the next few days a new code generator in
QE
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard08/01/21 15:07:18
Modified files:
. : softmmu_header.h
Log message:
fixed register constraint
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/softmmu_header.h?cvsroot
Johannes Schindelin wrote:
Hi,
On Mon, 21 Jan 2008, Fabrice Bellard wrote:
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard 08/01/21 15:07:18
Modified files:
. : softmmu_header.h
Log message:
fixed register constraint
CVSWeb URLs
Two questions:
- Why do you use AIO ? If the Linux sg device supports selects, then
using the QEMU select() callback suffices.
- Why do you use a block device ?
Regards,
Fabrice.
Laurent Vivier wrote:
> This series of patches makes some cleanups in SCSI passthrough and
> add functionnalities.
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard08/01/31 09:22:27
Modified files:
. : softmmu_template.h softmmu_header.h osdep.h
cpu-defs.h
Log message:
use simpler REGPARM convention - make
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard08/01/31 10:43:14
Removed files:
. : i386-vl.ld
Log message:
removed unused file
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/i386-vl.ld?cvsroot=qemu&r1=1.3&r2=0
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard08/01/31 11:32:10
Modified files:
. : Makefile Makefile.target configure
Log message:
Makefile cleanup - more generic support of 32 bit compilation on x86_64
CVSWeb URLs:
http
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard08/01/31 14:56:10
Modified files:
tests : test-i386.c
Log message:
compilation fixes - added bswap - comments
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/tests/test-i386
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard08/01/31 15:19:24
Modified files:
tests : Makefile
Log message:
compilation fix
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/tests/Makefile?cvsroot=qemu&r1=1.44&r2=1.45
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard08/01/31 15:19:39
Modified files:
tests : test-i386-code16.S
Log message:
suppressed warnings
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/tests/test-i386-code16.S
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard08/02/01 10:03:48
New directory:
tcg/x86_64
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/x86_64/?cvsroot=qemu
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard08/02/01 10:05:41
Added files:
tcg: LICENSE README TODO tcg-dyngen.c tcg-op.h
tcg-opc.h tcg-runtime.c tcg.c tcg.h
tcg/i386 : tcg-target.c tcg
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard08/02/01 10:03:35
New directory:
tcg
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/?cvsroot=qemu
Anthony Liguori wrote:
This patch actually enables KVM support for QEMU. I apologize that it is so
large but this was the only sane way to preserve bisectability.
The goal of this patch is to add KVM support, but not to impact users when
KVM isn't being used. It achieves this by using a kvm_en
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard08/02/01 10:02:52
Modified files:
. : Makefile
Log message:
typo
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile?cvsroot=qemu&r1=1.144&r2=1.145
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard08/02/01 10:03:18
Modified files:
. : TODO
Log message:
update
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/TODO?cvsroot=qemu&r1=1.40&r2=1.41
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard08/02/01 10:03:47
New directory:
tcg/i386
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/i386/?cvsroot=qemu
Anthony Liguori wrote:
KVM supports more than 2GB of memory for x86_64 hosts. The following patch
fixes a number of type related issues where int's were being used when they
shouldn't have been. It also introduces CMOS support so the BIOS can build
the appropriate e820 tables.
> [...]
+/
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard08/02/01 10:50:12
Modified files:
. : LICENSE Makefile.target configure cpu-all.h
cpu-defs.h cpu-exec.c dyngen.c exec-all.h
exec.c
Hi,
I added a new code generator (TCG) in QEMU. Read the file
qemu/tcg/README to have technical information. A new code generator was
needed in order to avoid problems with the various GCC versions and to
get better performance.
I made minimal modifications in each target so that they can st
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard08/02/01 13:01:47
Modified files:
tcg: README
Log message:
typos
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/README?cvsroot=qemu&r1=1.1&r2=1.2
Paul Brook wrote:
I agree with the fact that ram_size should be 64 bit. Maybe each
machine could test the value and emit an error message if it is too
big. Maybe an uint64_t would be better though.
uint64_t is probably more reasonable. I wouldn't begin to know what the
appropriate amount of ram
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard08/02/01 22:18:51
Modified files:
. : cpu-all.h cpu-exec.c qemu-doc.texi vl.c
Log message:
reverted -translation option support
CVSWeb URLs:
http://cvs.savannah.gnu.org
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard08/02/03 21:06:03
Modified files:
tcg/x86_64 : tcg-target.c
Log message:
compare fix
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/x86_64/tcg-target.c?cvsroot=qemu&r1
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard08/02/03 21:06:23
Modified files:
tcg/i386 : tcg-target.c
Log message:
compare fix
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/i386/tcg-target.c?cvsroot=qemu&r1=1.
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard08/02/04 00:37:54
Modified files:
tcg: README tcg-op.h tcg-opc.h tcg.c tcg.h
Log message:
fixed sign extensions - added explicit side effect op flag - added
discard instruction
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard08/02/04 22:26:57
Modified files:
linux-user : syscall.c
Log message:
lock_iovec() fix
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall.c?cvsroot=qemu&r1=1
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard08/02/04 22:03:16
Modified files:
tcg: tcg.c
Log message:
win32: suppress alloca() warning
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/tcg.c?cvsroot=qemu&r1
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard08/02/04 22:00:42
Modified files:
. : dyngen.c
Log message:
win32 fix
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/dyngen.c?cvsroot=qemu&r1=1.60&r2=1.61
Anthony Liguori wrote:
Johannes Schindelin wrote:
Hi,
On Tue, 5 Feb 2008, Anthony Liguori wrote:
I would really like to use OpenGL on non-Apple platforms. OpenGL
gives much better scaling than SDL. Typically, and OpenGL app has
very little platform specific code. It would be nice if we
Alexander Graf wrote:
> This is a resend of a mail I sent to the list on 2008/02/06. I felt it
> rather disturbing, yet normal that nobody cared about Mac OS X host
> support, but this concerns all x86 host OSs, so I believe this deserves
> some discussion.
>
> Hi,
>
> I've been trying to get the
Blue Swirl wrote:
> The attached patch enables most TCG ops for Qemu Sparc32/64 target.
> Sparc32 softmmu and linux-user are OK, but Sparc64 and Sparc32plus
> targets do not work.
>
> Comments?
>
> It would be nice to get rid of T2 usage in std (also stda and
> casa/casxa) but I don't know how to
> [...]
>> Another point is that you should define TCG globals for each SPARC GPR.
>> It was not done for i386 because I feared performance regressions when
>> accessing to 16 bit or 8 bit sub-registers. On SPARC you do not have
>> this issue.
>
> Nice idea. Would this also work for windowed r
Blue Swirl wrote:
> Hi,
>
> There is a problem with the Sparc32 target on i386 host. Store double
> word op (std) cannot be generated and TCG just aborts. It looks like
> the registers are so few on i386 that TCG can't find registers for the
> qemu_st64 call. The problem does not appear on x86_64
IMHO it would be much simpler to do all the tests in the block format
handlers.
Fabrice.
Aurelien Jarno wrote:
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Aurelien Jarno 08/03/11 17:17:59
Modified files:
. : block-qcow.c block-qcow2.c block-vmdk.c block.
Aurelien Jarno wrote:
> Fabrice Bellard a écrit :
>> IMHO it would be much simpler to do all the tests in the block format
>> handlers.
>>
>
> Do you mean move all the tests into block-{qcow,qcow2,vmdk}.c ?
I suggest reverting the patch and writing correct tests in
blo
Laurent Vivier wrote:
> This patch is a new version of qemu-img using NBD device to mount Qemu
> disk image.
>
> To not hang on UP system, it needs following patch:
> http://article.gmane.org/gmane.linux.drivers.nbd.general/42
> If you want to use loop to see partitions, you need this patch:
> htt
IMHO, calling floatX_round_to_int before floatX_to_intY is not useful...
Fabrice.
Thiemo Seufer wrote:
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer07/06/27 19:01:46
Modified files:
target-mips: op_helper.c
Log message:
Fix computation
floatX_to_intY should already do the rounding according to the current
rounding direction.
Fabrice.
Thiemo Seufer wrote:
Fabrice Bellard wrote:
IMHO, calling floatX_round_to_int before floatX_to_intY is not useful...
I don't understand. floatX_round_to_int does round/ceil/floor but
Hi,
In fact, running in 64 bit is not necessary : It is simpler and more
efficient to use kqemu (or KVM) to handle the address space remapping.
The trick is to run the translator in the upper part or lower part of
the 32 bit address space and to protect it with segments.
Even in 64 bit mode,
Blue Swirl wrote:
On 6/29/07, Fabrice Bellard <[EMAIL PROTECTED]> wrote:
In fact, running in 64 bit is not necessary : It is simpler and more
efficient to use kqemu (or KVM) to handle the address space remapping.
The trick is to run the translator in the upper part or lower part of
the
Please update page_check_range() (and other related functions) to return
-EFAULT instead of EFAULT in case of error.
Moreover, I believe using similar functions as Linux for memory access
(copyfromuser, copytouser, get_user, put_user) would be cleaner.
Regards,
Fabrice.
Stuart Anderson wrot
Stuart Anderson wrote:
On Fri, 6 Jul 2007, Stuart Anderson wrote:
So, the question is:
Can I simplify this code to assume that guest and
host addresses coexist and use the copy_*_user() or
just the access_ok() interfaces?
No. Ideally you should use the same conventions as the Lin
Paul Brook wrote:
(...]
Using g2h directly is bad. g2h is an implementation detail of one particular
memory model.
The whole point of the lock_user abstraction (or a similar copy_from_user
abstraction) is that almost none of the code cares how "user" memory is
accessed. One of the long-term g
Paul Brook wrote:
On Friday 24 August 2007, Blue Swirl wrote:
I have now converted the ISA DMA devices (SB16, FDC), most PCI devices
and targets.
gdma.diff: Generic DMA
pc_ppc_dma_to_gdma.diff: Convert x86 and PPC to GDMA
pc_sb16_to_gdma.diff: Convert SB16 to GDMA
pc_fdc_to_gdma.diff: FDC
pc_dm
This is a reworked version of the same patch, where I can now boot into
a x86_64 Linux kernel.
I rewrote all the access functions for the VMCB, so this time everything
should work just fine on BE-machines. As suggested I moved the injection
detection to translate.c, so the non-virtualized machin
Paul Brook wrote:
pci_gdma.diff: Convert PCI devices and targets
Any comments? The patches are a bit intrusive and I can't test the
targets except that they compile.
Shouldn't the PCI DMA object be a property of the PCI bus?
ie. we don't want/need to pass it round as a separate parameter. It ca
Alexander Graf wrote:
Hi,
I'm still trying to implement SVM correctly and hit a serious problem.
If I set CC_OP to EFLAGS / DYNAMIC after each instruction (so most
conditional operations are based on EFLAGS) everything works as expected.
If using CC_OP==CC_OP_EFLAGS only CC_SRC should be used an
Anthony Liguori wrote:
On Tue, 2007-09-04 at 23:27 +0100, Thiemo Seufer wrote:
Brian Johnson wrote:
[snip]
My initial thought is to make the libraries at the individual device
level.
It would be good to have a general mechanism for bus providers, interrupts,
APICs, chipsets, etc. as well,
Hi,
The code would be simpler if some intercept tests were done at runtime
in the corresponding helpers (for crN, drN and MSR registers, I/Os).
This is especially true when the existing helpers can return an
exception at runtime. Complicating the translator to handle SVM is
definitely not the
Hi,
I don't think this is the right fix because the monitor expressions can
be used for either virtual or physical addresses. I suggest using 64 bit
integers for every target.
Fabrice.
Blue Swirl wrote:
CVSROOT:/cvsroot/qemu
Module name:qemu
Changes by: Blue Swirl 07/09/
Try to avoid using target_phys_addr_t at this place as I don't want this
code to be CPU dependent (think of a machine having several different
CPUs !).
Regards,
Fabrice.
Blue Swirl wrote:
CVSROOT:/cvsroot/qemu
Module name:qemu
Changes by: Blue Swirl 07/09/24 18:41:27
Mod
The problem must come from somewhere else. VGA (as any other device)
must not depend on the target CPU endianness (note that the endianness
tests in the memory handlers are only necessary because the bus API is
still incomplete).
Regards,
Fabrice.
Stefan Weil wrote:
Hello,
here is a patch
I realize that the other pixel formats are buggy too, so at least your
patch is consistent with what is already coded !
I guess the problem is in the VGA memory handlers. Otherwise it means
that there is a (Cirrus)VGA configuration register to change the
endianness of the frame buffer. In such
andrzej zaborowski wrote:
Hi,
On 24/09/2007, Dan Kenigsberg <[EMAIL PROTECTED]> wrote:
As with previous "Takes" of this patch, its purpose is to expose host
CPU features to guests. It proved rather helpful to KVM in various
benchmarks, and it should similarly speed kqemu up. Note that it does
Avi Kivity wrote:
J. Mayer wrote:
On Tue, 2007-09-25 at 12:40 +0200, Avi Kivity wrote:
Avi Kivity wrote:
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. Th
Aurelien Jarno wrote:
Hi,
As written in the MIPS TODO file, the lwl, lwr, ldl, ldr, swl, swr,
sdl and sdr instructions are not correctly implemented. In case of
exception the BadVAddr register gets the aligned address instead of the
unaligned original address.
In addition to that, the store i
Aurelien Jarno wrote:
Hi,
As written in the MIPS TODO file, the lwl, lwr, ldl, ldr, swl, swr,
sdl and sdr instructions are not correctly implemented. In case of
exception the BadVAddr register gets the aligned address instead of the
unaligned original address.
In addition to that, the store i
Blue Swirl wrote:
On 10/1/07, Jocelyn Mayer <[EMAIL PROTECTED]> wrote:
On Mon, 2007-10-01 at 17:55 +0300, Blue Swirl wrote:
On 10/1/07, Andreas Färber <[EMAIL PROTECTED]> wrote:
Am 01.10.2007 um 09:12 schrieb Bob Deblier:
Ideally we should have an OpenBIOS compiled for QEMU/PPC. Is anyone
wo
J. Mayer 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
bits target in linux user mode emulation.
> [...]
Are you sure it is a good idea to try to add 32 bit executable support
to a 64 bit ta
Thiemo Seufer wrote:
Fabrice Bellard wrote:
J. Mayer 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
bits target in linux user mode emulation.
[...]
Are you sure it is a good idea to try to
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 is that a translated block is never to span over a page
boundary. As the t
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 is that a translated block is never to span over a page
boundary. As the t
Paul Brook wrote:
> [...]
The code itself looks ok, though I'd be surprised if it made a
significant difference. We're always going to hit the fast-path TLB
lookup case anyway.
It seems that the generated code for the code fetch is much more
efficient than the one generated when we get when usi
> I tried harder to change the SLIRP queue stuff to something saner by
> hiding the pointer access inside inlined functions. Still when I
> changed the 32 bit pointers to native 64 bit (or moved the pointers
> outside the packet), qemu crashes. Must be some devilishly hidden
> access somewhere. I
I strongly suggest to reuse my code which was in target-i386/helper.c
revision 1.80 which was far easier to validate. Moreover, integer
divisions from target-i386/helper.c should be put in the same file.
Regards,
Fabrice.
Thiemo Seufer wrote:
CVSROOT:/sources/qemu
Module name:qem
Jocelyn Mayer wrote:
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 easier to validate. Moreover, integer
Blue Swirl wrote:
> Hi,
>
> With the automatic dependency rule installed, modifying vl.h causes
> all files to be recompiled. This is of course the correct action, but
> it's a major slowdown for development too.
There must be an option in the Makefile to disable the automatic
dependency check.
I think that using host addresses in __put_user and __get_user is not
logical. They should use target addresses as get_user and put_user. As
Paul said, It is not worth mixing get/put/copy and lock/unlock functions.
The ultimate goal of such cleanup is not only to generate -EFAULT
correctly but als
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 wrote:
>> [...]
>> But it could be great to group the syscalls by
>> categories, or so. For example, putting all POSIX compliant syscalls in
>> a single file and using a
Blue Swirl wrote:
> Hi,
>
> RISC CPUs don't support self-modifying code unless the affected area
> is flushed explicitly. This patch disables the extra effort for SMC.
> The changes in this version would affect all CPUs except x86, but I'd
> like to see if there are problems with some target, so t
Thomas Bleher wrote:
Thiemo Seufer told me that GPLv2 is fine for qemu, therefore I'd like to
ask that this patch be included in qemu as I posted it (the second
version with the clarified GPLv2 license).
I prefer that a BSD style license is used, especially if the code just
contains wrappers.
Thayne Harbaugh wrote:
> On Sat, 2007-11-03 at 20:05 +0100, Fabrice Bellard wrote:
>> I think that using host addresses in __put_user and __get_user is not
>> logical. They should use target addresses as get_user and put_user. As
>> Paul said, It is not worth mixing get/put
Thayne Harbaugh wrote:
> On Mon, 2007-11-05 at 22:42 +0100, Fabrice Bellard wrote:
>> Thayne Harbaugh wrote:
>>> On Sat, 2007-11-03 at 20:05 +0100, Fabrice Bellard wrote:
>>>> I think that using host addresses in __put_user and __get_user is not
>>>> lo
Thomas Bleher wrote:
> * Fabrice Bellard <[EMAIL PROTECTED]> [2007-11-05 16:40]:
>> Thomas Bleher wrote:
>>> Thiemo Seufer told me that GPLv2 is fine for qemu, therefore I'd like to
>>> ask that this patch be included in qemu as I posted it (the second
>&g
Paul Brook wrote:
> [...]
> Personally I like the locking interface as it allows a zero-copy
> implementation. However the kernel uses a copying interface, and my
> understanding is that other qemu maintainers also prefer the copying
> interface.
At least I don't think it is critical performanc
Stefan Weil wrote:
> Hi,
>
> the change from mc146818rtc.c might be needed for other timer
> implementations,
> too (because not all systems emulated by QEMU use mc146818rtc.c).
>
> A list of candidates is here (fgrep gmtime, fgrep gettime):
> hw/m48t59.c:gmtime_r (&t, tm);
> hw/omap.c:
Hi,
Regarding the user memory access, here is my suggestion which should
minimize the changes:
- Keep __put_user() and __get_user() as you did.
- Remove put_user(), get_user(), copy_from_user() and copy_to_user()
- Modify the signal.c code so that it uses __put_user, __get_user and
lock/unlock_
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard07/11/07 19:24:02
Modified files:
. : Makefile Makefile.target
Log message:
compile common code once
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile?cvsroot
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard07/11/07 19:25:15
Modified files:
. : configure
Log message:
SDL and COCA are no longer target dependent - support for common code
compilation
CVSWeb URLs:
http
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard07/11/07 19:26:23
Modified files:
. : vl.h
Log message:
fixed QEMU_TOOL tests
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemu&r1=1.288&r2=1.289
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard07/11/07 19:26:55
Modified files:
audio : audio.h
Log message:
use config-host.h instead of config.h
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/audio/audio.h?cvsroot
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard07/11/07 19:27:18
Modified files:
slirp : slirp.h
Log message:
use config-host.h instead of config.h
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/slirp/slirp.h?cvsroot
I noticed that some target CPUs macros have been added while they do not
seem necessary. I don't like that because it introduces more #ifdefs
which prevent making a version supporting simultaneously all the CPUs.
In particular I saw the following:
- TARGET_MIPSN32 : it is always combined with TAR
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard07/11/07 16:54:42
Modified files:
hw : pc.c
Log message:
removed traces
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pc.c?cvsroot=qemu&r1=1.88&r2=1.89
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard07/11/07 16:24:34
Modified files:
. : qemu-doc.texi vl.c vl.h
hw : mc146818rtc.c
Log message:
added -startdate option
CVSWeb URLs:
http
1 - 100 of 1185 matches
Mail list logo
