[Qemu-devel] X86-64 and APIC
Dear List, Natalia Portillo noticed that XP_64 refused to install due to lack of APICs. Filip Navara proposed an initial patch, and Fabribe Bellard proposed : I can include the patch with a specific option to enable it. The option will disapear when the hack will be known to be stable. Fabrice then commited (in July) three APIC-related patches ; the current (0.7.2) documentation does not mention APICs. I was therefore under the impression that this was a solved issue. However, trying to use qemu-system-x86_64 (with kqemu) on an AMD64 system (running under Ubuntu AMD 64 with a hand-compiled (with gcc-3.4.5) kernel) to test XP Pro_64 leads to no installation : the system complains that it can see no APIC and cannot continue. Is there an (undocumented) option to enable APIC emulation in this configuration (qemu-system-x86-64 + kqemu running under Linux 2.6.12 64 bits) ? Or did I hit an unsupported case ? Emmanuel Charpentier ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] X86-64 and APIC
Emmanuel Charpentier wrote: Dear List, Natalia Portillo noticed that XP_64 refused to install due to lack of APICs. Filip Navara proposed an initial patch, and Fabribe Bellard proposed : I can include the patch with a specific option to enable it. The option will disapear when the hack will be known to be stable. Fabrice then commited (in July) three APIC-related patches ; the current (0.7.2) documentation does not mention APICs. I was therefore under the impression that this was a solved issue. However, trying to use qemu-system-x86_64 (with kqemu) on an AMD64 system (running under Ubuntu AMD 64 with a hand-compiled (with gcc-3.4.5) kernel) to test XP Pro_64 leads to no installation : the system complains that it can see no APIC and cannot continue. Is there an (undocumented) option to enable APIC emulation in this configuration (qemu-system-x86-64 + kqemu running under Linux 2.6.12 64 bits) ? Or did I hit an unsupported case ? Sigh, people write me private mails about this every month. The problem with Win64 is not APIC, but ACPI (which is used to detect Local APIC among other things). I've updated version of my hack and experimental ACPI implementation from malc_, but even with these patches it's NOT POSSIBLE to install Win64. With all the local patches in my tree I'm able to get to the second stage setup, but that's all ... it's way too slow for some reason (not just normal slowness, but some bug probably). - Filip ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [patch] IDE busmaster DMA support
On Mon, 2005-09-26 at 21:48 -0400, John Coiner wrote:
Can anyone shed light on the potential performance to be realized? For
example, how long does a context switch take in the guest? If it takes
10ms (one disk seek) then there's probably no benefit to concurrent disk
IO. If a context switch takes 1ms, then the guest has opportunity to
make forward progress while awaiting an IDE interrupt.
I ran this code to time context switches:
#include sys/time.h
#include time.h
#include unistd.h
#include stdlib.h
#include stdio.h
#include string.h
int main(int argc, char *argv[]) {
struct timeval start;
gettimeofday(start, NULL);
int fd[2];
pipe(fd);
int child = fork();
int i, count = 10;
char *msg = malloc(2);
strcpy(msg, m);
for (i = 0; i count; i++) {
if (child) {
if (write(fd[1], msg, 1) != 1)
fprintf(stderr, FAILURE\n);
} else {
if (read(fd[0], msg, 1) != 1)
fprintf(stderr, FAILURE\n);
}
}
struct timeval end;
gettimeofday(end, NULL);
printf(%g microseconds/context switch\n,
(((end.tv_sec - start.tv_sec) * (double)100) +
end.tv_usec - start.tv_usec)/count);
return 0;
}
On my dual 2.4 Ghz Xeon, I get the following timings.
host:~ ./yieldtest
2.35418 microseconds/context switch
2.35414 microseconds/context switch
KNOPPIX guest: ./yieldtest
105.092 microseconds/context switch
105.184 microseconds/context switch
Is that what you are after?
--
Joe Batt [EMAIL PROTECTED]
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [patch] IDE busmaster DMA support
On Mon, Sep 26, 2005 at 09:48:25PM -0400, John Coiner wrote: Hi, Here's another patch to enable IDE DMA: http://people.brandeis.edu/~jcoiner/qemu_idedma/qemu_dma_patch.html This patch, like Juergen Lock's earlier patch from which it is derived, replaces the virtual PIIX3 IDE controller with a PIIX4. It applies cleanly to 0.7.2. This patch extends the Windows 2000 install hack to work for DMA also -- I installed and ran Windows 2000 with DMA enabled. It'd be cool if QEMU supported nonblocking disk access -- if it would let the guest resume running currently, while waiting for the disk to finish seeking. This patch is a first step toward concurrent IO, which would probably have to use busmastering DMA transfers to be efficient, if it's going to be efficient at all. Do people have ideas about how to implement concurrent IO? I have a couple hazy ideas... Can anyone shed light on the potential performance to be realized? For example, how long does a context switch take in the guest? If it takes 10ms (one disk seek) then there's probably no benefit to concurrent disk IO. If a context switch takes 1ms, then the guest has opportunity to make forward progress while awaiting an IDE interrupt. I would strongly suggest attempting to make use of the Linux Async I/O support.. this way the data from disk could be placed directly in address space of the guest OS. Personally, I'd love to see nonblocking disk IO. I've tried running Qemu using a disk image on an AFS filesystem, and having the guest be able to continue while the filesystem is fetching data from the network would make things much nicer. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [EMAIL PROTECTED];~Be5U1g(B
[EMAIL PROTECTED];~Be5U1g(B
http://1191.jp/Rc/purejewelry/index.html
$B!Z(BPure$B!!(BJewelry$B![(B
[EMAIL PROTECTED],:[EMAIL PROTECTED]:G9b$N=P0)$$$N[EMAIL
PROTECTED]+Ii$7$F$*$j$^$9!#:#$^$G$N=P0)[EMAIL
PROTECTED]($O(B75$B!s$rD6$(!$?$/$5$s$N3'MM$+$i$*Ni$NOMm$rD:$$$F$*$j$^$9!#$3$l$+$i$bAGE($JNx$r$$$D$^$G$bB3$1$i$l$k$3$H$r4j$C$F$*$j$^$9!#(B
http://1191.jp/Rc/purejewelry/index.html
---
[EMAIL PROTECTED]'MM$KAGE($J=P0)$$$r4j$C$F$*$j$^$9!#4{:'[EMAIL
PROTECTED][EMAIL
PROTECTED]:!$$$D$^$G$bAGE($JNx$r$7$F$$$?$$$H;W$$N$OEvA3$G$9!#$=$3$G![EMAIL
PROTECTED]'MM$K%5!%S%9NA!J%G!%HBe!%[%F%kBeEy!=P0)$C$?$H$-$KH/@8$9$k$*6b!K$r$*;YJ'$$$7![EMAIL
PROTECTED]:]$r$7$FD:$1$?$i%9%`!%:$K=P0)$$$,$$k$N$G$O$J$$$G$7$g$$+!)(B
http://deai.ecdrf.com/?himitu
[EMAIL PROTECTED]'MM$K$O?HJ,3NG'Ey$N?3::$,$4$6$$$^$9!#$4N;5$/[EMAIL
PROTECTED];!#(B
---
[EMAIL PROTECTED]'MM$X!z(B
[EMAIL PROTECTED];W$$$^$9$,!!Z(BPure$B!!([EMAIL PROTECTED])$$$N[EMAIL
PROTECTED];W$$$d$jEy:GDc8B$N%^%J!$r$*i$j$K$J$jAGE($J=P0)$$$r$7$FD:[EMAIL
PROTECTED]'MM$O?3::$O$$j$^$;$s!#EPO?%3!%J!$h$j%W%m%U%#!%k$r$4EPO?$/[EMAIL
PROTECTED];!#(B
http://1191.jp/Rc/purejewelry/index.html
$B:#8eu?.5qH]$9$kJ}$O([EMAIL PROTECTED]/[EMAIL PROTECTED](B
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] SPARC patch for OS X (big endian machines)
Without the following patch, I was unable to start the Linux boot
process
on OS X (powerPC bigendian). I tried on ia64 (Linux) and works fine too.
--- target-sparc/op_helper.c23 Jul 2005 14:27:54 - 1.15
+++ target-sparc/op_helper.c27 Sep 2005 23:54:52 -
@@ -225,4 +225,5 @@
void helper_ld_asi(int asi, int size, int sign)
{
+
uint32_t ret = 0;
@@ -258,8 +259,12 @@
case 0x20 ... 0x2f: /* MMU passthrough */
cpu_physical_memory_read(T0, (void *) ret, size);
- if (size == 4)
- tswap32s(ret);
-else if (size == 2)
- tswap16s((uint16_t *)ret);
+
+ tswap32s(ret);
+ if (size == 2) {
+ ret = ret 16;
+ }else if (size == 1) {
+ ret = ret 24;
+ }
+
break;
default:
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
