Re: [kvm-devel] [Qemu-devel] Fixing ACPI for Vista -- Source code for bios.bin vs. bochs CVS?
Paul Brook wrote:
On Monday 30 April 2007, Nakajima, Jun wrote:
We found a way to get 32-bit Vista up on KVM by fixing bios.bin. And I
think it should be helpful to qemu as well. However, I'm not sure if the
binary file has been created simply by applying bios.diff to the latest
bochs CVS tree (actually I doubt it).
What makes you think this won't work? Have you tried it?
Regardless of whether it works or not, it would be nice to have a file
in qemu/pc-bios detailing the revision numbers of the sources taken from
bochs, synced on each update. Something like the output of
cvs status | awk '/^File:/ { file = $2 } /^ Working revision:/ {
printf(%-20s %s\n, file, $3) }'
--
error compiling committee.c: too many arguments to function
[Qemu-devel] Re: [kvm-devel] Fixing ACPI for Vista -- Source code for bios.bin vs. bochs CVS?
Howdie, Nakajima, Jun wrote: We found a way to get 32-bit Vista up on KVM by fixing bios.bin. And I think it should be helpful to qemu as well. However, I'm not sure if the binary file has been created simply by applying bios.diff to the latest bochs CVS tree (actually I doubt it). Can somebody provide a recipe for creating bios.bin from the bochs tree so that we can make a patch? While we wait patiently for the patch, would you mind putting the patched bios.bin somewhere accessible (or sending it to me in private email and I'll put it somewhere accessible)? There's a bunch of geeks here that would really like to best test this... :-) Thanks! Gilad -- Gilad Ben-Yossef [EMAIL PROTECTED] Codefidence. A name you can trust(tm) http://www.codefidence.com Phone: +972.3.7515563 ext. 201 | Cellular: +972.52.8260388 SIP: [EMAIL PROTECTED] | Fax: +972.3.7515503
Re: [Qemu-devel] qemu vl.h hw/arm_boot.c hw/integratorcp.c hw/re...
On Mon, 2007-04-30 at 02:24 +, Andrzej Zaborowski wrote: Account for machine with RAM which is not mapped at 0x0 in arm_boot.c. It seems a pity that you did this in a manner which didn't match the patch I published for the Simtec BAST boards. Now I have a bunch more merging effort to go through if I'm ever to get this patch merged. (Not that anyone has said a word to me since I posted it having solved all the issues that pbrook raised) In particular you call the variable loader_start which seems somewhat misleading since essentially what it is is the emulated_sdram_base which is what I called it. I guess I'll have to do some serious merge work into my working tree and then post another patch. If you're interested. If not then I'll just carry on in my own little world and not bother with submitting to trunk, which seems a serious pity as it simply ends up being more work for all concerned and it forks the project. Hopefully we can come to some agreement about this which isn't a schism in processes. Regards, Daniel -- Daniel Silverstone http://www.simtec.co.uk/ PGP mail accepted and encouraged.Key Id: 2BC8 4016 2068 7895
Re: [Qemu-devel] [PATCH] qemu Makefile.target qemu-doc.texi vl.c vl.h hw...
Hi,
there was a small spelling bug in the new description which is fixed by
this patch.
The patch also updates the list of supported network cards.
Regards
Stefan
Index: qemu-doc.texi
===
RCS file: /sources/qemu/qemu/qemu-doc.texi,v
retrieving revision 1.139
diff -u -b -B -r1.139 qemu-doc.texi
--- qemu-doc.texi 30 Apr 2007 02:22:06 - 1.139
+++ qemu-doc.texi 1 May 2007 11:10:57 -
@@ -357,10 +357,12 @@
= 0 is the default). The NIC is currently an NE2000 on the PC
target. Optionally, the MAC address can be changed. If no
@option{-net} option is specified, a single NIC is created.
-Qemu can emulate several different models of network card. Valid values for
[EMAIL PROTECTED] are @code{ne2k_pci}, @code{ne2k_isa}, @code{rtl8139},
[EMAIL PROTECTED] and @code{lance}. Not all devices are supported on all
-targets.
+Qemu can emulate several different models of network card.
+Valid values for @var{type} are
[EMAIL PROTECTED], @code{i82557b}, @code{i82559},
[EMAIL PROTECTED], @code{ne2k_isa}, @code{pcnet}, @code{rtl8139},
[EMAIL PROTECTED] and @code{lance}.
+Not all devices are supported on all targets.
@item -net user[,vlan=n][,hostname=name]
Use the user mode network stack which requires no administrator
@@ -1801,7 +1805,7 @@
@item
GPIO-connected keyboard controller and LEDs
@item
-Secure Digital card conntected to PXA MMC/SD host
+Secure Digital card connected to PXA MMC/SD host
@item
Three on-chip UARTs
@item
[Qemu-devel] qemu qemu-doc.texi vl.c vl.h hw/sun4m.c hw/sun4u.c
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl blueswir1 07/05/01 14:16:52 Modified files: . : qemu-doc.texi vl.c vl.h hw : sun4m.c sun4u.c Log message: Set OpenBIOS variables in NVRAM CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu-doc.texi?cvsroot=qemur1=1.139r2=1.140 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.292r2=1.293 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.232r2=1.233 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sun4m.c?cvsroot=qemur1=1.34r2=1.35 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sun4u.c?cvsroot=qemur1=1.16r2=1.17
Re: [Qemu-devel] qemu vl.h hw/arm_boot.c hw/integratorcp.c hw/re...
Hi, On 01/05/07, Daniel Silverstone [EMAIL PROTECTED] wrote: On Mon, 2007-04-30 at 02:24 +, Andrzej Zaborowski wrote: Account for machine with RAM which is not mapped at 0x0 in arm_boot.c. It seems a pity that you did this in a manner which didn't match the patch I published for the Simtec BAST boards. Now I have a bunch more merging effort to go through if I'm ever to get this patch merged. (Not that anyone has said a word to me since I posted it having solved all the issues that pbrook raised) Your fix was almost identical to what I merged (and what I published in January) so I don't think this is much to pity. Generally when there are two versions of the same code, what is merged is bound to not match at least one of them, however in this case this is really no cause for a lot of rediffing effort. In particular you call the variable loader_start which seems somewhat misleading since essentially what it is is the emulated_sdram_base which is what I called it. There's no reason for the bootloader to be always at the start of SDRAM. It is at the start of some ROM in most real life cases, but could be anywhere. I guess I'll have to do some serious merge work into my working tree and then post another patch. If you're interested. If not then I'll just carry on in my own little world and not bother with submitting to trunk, which seems a serious pity as it simply ends up being more work for all concerned and it forks the project. Regarding the S3C2410 emulation we have done some of the same work and this is never a nice thing and we'll have to figure a couple of things out. Let me describe what would be optimal for me: At some point we would start working with a single tree (outside mainline). Considering that our S3C2410 implementation seems more complete I would leave this implementation in that tree and base the Simtec BAST machine on this implementation of the CPU. Switching the machine code from using your implementation of the CPU should be easy because both versions seem to have a clean api. I can try to do this. Since you decided to ask for inclusion I assume that your tree is not undergoing any huge changes anymore. However our tree is still heavily evolving, thus I would be in charge of keeping the tree updated with changes from mainline, until the point where we're *both* happy to upstream. I believe the area we're improving at this moment in the S3C2410 code is not overlapping with any of your work so there's no hurry. If anyone else is working on a machine based on S3C2410 they could also do that in that common tree outside mainline. Regarding slowness of the Interrupt Controller, I aimed to be correct with the datasheet and implemented the arbitration algorithm (or something similar to it) but I didn't mean for it to be enabled on normal emulator runs. As you perhaps noticed the arbitration would only have any effect in rare, little significant cases in which the outcome is hazardous to rely on anyway - and even the hardware implementation is probably not 100% correct. Moreover Paul already found places in which my implementation is not even what the datasheet describes, so this has to be changed anyway - however I don't see anything wrong having the code present. Also I don't believe the performance difference noticeable. Regards, Andrzej
[Qemu-devel] qemu qemu-doc.texi
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski balrog 07/05/01 17:53:37 Modified files: . : qemu-doc.texi Log message: Correct a docs typo and list of available NIC names (by Stefan Weil). CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu-doc.texi?cvsroot=qemur1=1.140r2=1.141
Re: [Qemu-devel] Re: Detecting an assembly instruction in QEMU
Hi Eduardo, Is it possible to identify context switches inside QEMU. In order to support transactional memory in QEMU, we have added target_ulong tm_abort_eip; int inTransaction; to CPUX86State structure. tm_abort_eip is the EIP to jump to when a transaction fails i.e. start of the Transactional Block while inTransaction tells us whether a transaction has started so that we can log the memory references. As far as I understand, env variable will be modified at a context switch. At a context switch, we need to update tm_abort_eip as well as inTransaction based on the status of the new thread being loaded. We can store these two variables inside DisasContext which I believe is unique for each translated block. But when and where should we modify the env variable so that for each thread it contains the correct values for tm_abort_eip and inTransaction. I will appreciate your help. Thanks, Atif On 4/27/07, Eduardo Felipe [EMAIL PROTECTED] wrote: I think I could not explain my question regarding addl %ebx, (%eax). What I wanted to ask was that this instruction also accesses the memory and I also need to intercept it within a transaction. Incase of addl %ebx, (%eax), Are the functions under /* CPU memory access without any memory or io remapping */ called in case of this instruction. Yes. Just look how the instruction is translated into opcodes and you'll see how it works. You can use the -d switch for this. Secondly, there is a function in exec.c called cpu_physical_memory_rw. Is it easier to hack into this fuction to intercept the memory references. That function is used by emulated hardware devices to interact with memory ( e.g. DMA to write and read memory chunks). Translated guest code does not use it. Regards, Eduardo
[Qemu-devel] Re: Fixing ACPI for Vista -- Source code for bios.bin vs.bochs CVS?
I added -fno-stack-protector into the line 103 of the makefile in the bios directory and was able to compile it. rombios32.o: rombios32.c acpi-dsdt.hex $(GCC) -O2 -Wall -fno-stack-protector -c -o $@ $ It looks like qemu works fine even with unmodified bochs's bios. However, I still could not boot the latest beta of Vista, no matter if I applied bios.diff or not. I don't have the release version of Vista. Alex. Nakajima, Jun [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] We found a way to get 32-bit Vista up on KVM by fixing bios.bin. And I think it should be helpful to qemu as well. However, I'm not sure if the binary file has been created simply by applying bios.diff to the latest bochs CVS tree (actually I doubt it). Can somebody provide a recipe for creating bios.bin from the bochs tree so that we can make a patch? Thanks, Jun --- Intel Open Source Technology Center - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
[Qemu-devel] qemu-cvs-2007-5-2 compile error
make[1]: Entering directory `/home/hys545/qemu/arm-softmmu' gcc33 -Wall -O2 -g -fno-strict-aliasing -I. -I.. -I/usr/src/Haansoft/BUILD/qemu/target-arm -I/usr/src/Haansoft/BUILD/qemu -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/usr/src/Haansoft/BUILD/qemu/fpu -DHAS_AUDIO -DHIGH_LATENCY -I/usr/src/Haansoft/BUILD/qemu/slirp-c -o alsaaudio.o /usr/src/Haansoft/BUILD/qemu/audio/alsaaudio.c /usr/src/Haansoft/BUILD/qemu/audio/alsaaudio.c: In function `alsa_open': /usr/src/Haansoft/BUILD/qemu/audio/alsaaudio.c:359: error: `DEFAULT_BUFFER_SIZE' undeclared (first use in this function) /usr/src/Haansoft/BUILD/qemu/audio/alsaaudio.c:359: error: (Each undeclared identifier is reported only once /usr/src/Haansoft/BUILD/qemu/audio/alsaaudio.c:359: error: for each function it appears in.) /usr/src/Haansoft/BUILD/qemu/audio/alsaaudio.c:360: error: `DEFAULT_PERIOD_SIZE' undeclared (first use in this function) make[1]: *** [alsaaudio.o] 오류 1 make[1]: Leaving directory `/home/hys545/qemu/arm-softmmu' - Your Life on the Net DreamWiz Free Mail @ http://www.dreamwiz.com/
[Qemu-devel] qemu Makefile.target audio/alsaaudio.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski balrog 07/05/02 02:11:51 Modified files: . : Makefile.target audio : alsaaudio.c Log message: Don't define HIGH_LATENCY for ARM, this was a workaround for an ALSA problem. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemur1=1.166r2=1.167 http://cvs.savannah.gnu.org/viewcvs/qemu/audio/alsaaudio.c?cvsroot=qemur1=1.8r2=1.9
