[Qemu-devel] 3D acceleration

[Gervase Lam]

> From: Alexander Graf
> Subject:  Re: [Qemu-devel] [patch] cocoa.m - Core Graphics support
> Date: Thu, 31 Jan 2008 09:29:02 +0100

> I somehow like the idea of having a GL based video output.

Awhile back, somebody did a patch to allow guest accelerated Windows
OpenGL graphics.  From what I can tell, he basically wrote a Windows
OpenGL API that 'calls' interrupts, which QEMU traps.  QEMU then
interprets the interrupts and calls the OpenGL API of the Linux host.



In the thread is also the interesting suggestion of using the dlxgl
wrapper API to convert Direct3D to OpenGL in Windows.  This
theoretically means that you could run Direct3D apps in QEMU.

I think it would be worthwhile getting Direct3D and OpenGL to work on
QEMU.  This is especially when Win95/98 cannot run on the more up-to-
date PC chipsets (due to manufacturers not being will to provide drivers
or whatever).  I know of a least two applications that can run on
Win95/98 but not XP.

Fabrice made a comment on this patch:



>From my minimal understanding of what he is saying, it seems he would
prefer there to be a BOCHS graphics adapter, which would then pass the
OpenGL commands from Windows to Linux OpenGL.  Also, Direct3D commands
would be passed from Windows to Linux Wine.

I wouldn't mind having a go at this as I would like to run 3D
accelerated Windows apps on Linux.  However, due to a couple of other
projects I want to complete first (including a PC upgrade), I don't
think I'll have time to do this until may be later this year.  Also, I
will need to do some learning.  So don't your breath.  Anybody want to
volunteer to do this?

What are people's current feelings about this?  I've been wanting to run
3D accelerated Win98/95 in Linux (on what will be an up-to-date chipset
soon...).  But I kept on finding out about PCI  pass through on Xen to
allow Direct3D to do its work, and the open "source" specifications of
ATI cards (though I read that nVidia are allegedly deliberating about
doing the same thing sometime this year).

Thanks,
Gervase.

[Qemu-devel] RE: [kvm-ia64-devel] [kvm-devel] [PATCH] Making SLIRP code more64-bit clean

[Zhang, Xiantao]

Scott Pakin wrote:
> Zhang, Xiantao wrote:
>> Scott Pakin wrote:
>>> The attached patch corrects a bug in qemu/slirp/tcp_var.h that
>>> defines the seg_next field in struct tcpcb to be 32 bits wide
>>> regardless of 32/64-bitness.  seg_next is assigned a pointer value
>>> in qemu/slirp/tcp_subr.c, then cast back to a pointer in
>>> qemu/slirp/tcp_input.c and dereferenced.  That produces a SIGSEGV on
>>> my system.
>> 
>> 
>> I still hit it on IA64 platform with your patch, once configured with
>> slirp.

Scott
With the enhanced patch, IA64 guests works well. Great!!  If
this fix be picked up, we can remove the configure option which excludes
slirp compile for kvm/ia64. 
Thanks!
Xiantao

Re: [Qemu-devel] More about slow clock in guest OS

[Mulyadi Santosa]

hello Sergey...

On 1/31/08, Sergey Bychkov <[EMAIL PROTECTED]> wrote:
> As I can see, this document anything about what to do if qemu hung :)

reading always helps in some degree :)

> After some investigations I can say that with the latest (2008/01/30) qemu
> from cvs, compiled with gcc-3.4 on linux x86_64 host, guest OS win2k3 works
> not too good.
So, in other words "it works but not so well". may I interpret it as a progress?

> With "-clock dynticks" clock in OS is very slow - and windows time server
> can't adjust.

Probably due to cost of Qemu timer rearming. And maybe Windows 2003
does certain dyntick by its own...thus enlarging the timer rearming
cost.

> With "-clock rtc" hung periodically - for up to 5 minutes, 300 seconds.

p... too much timers get expired? lock contention somewhere...anybody?

>This
> could happen at bootstrap - when no OS, only BIOS. Then it resumes and works
> for some random period of time, then hangs again, and so on. This behaviour
> doesn't depend on guest OS, and was reproduced with Knoppix live CD. Note
> that host should be periodically busy executing something like torrent
> client.
Thus..maybe it's Qemu's fault...

> Details and startup scripts:
>
> $ cat knoppix-qemu-nographic.sh
> ==
> QEMU=$HOME/bin/qemu-system-x86_64
> [ -x "$QEMU" ] || QEMU=/usr/bin/qemu-system-x86_64
> sudo modprobe kqemu
> echo will use executable $QEMU
> DIR=`dirname $0`
> [ -z "$DIR" -o "$DIR" == "." ] && DIR=`pwd`
> echo DIR is $DIR
> PREV_RTC_FREQ=`cat /proc/sys/dev/rtc/max-user-freq`
> [ "$PREV_RTC_FREQ" -ge "1024" ] || echo 'WARN: RTC FREQ too slow:'
> $PREV_RTC_FREQ
> sudo $QEMU -net nic,model=rtl8139,macaddr=52:54:00:80:80:01 -net
> tap,script=$DIR/qemu-ifup-br0,downscript=$DIR/qemu-ifdown-br0 -localtime 
> -cdrom
> /distrib/knoppix/KNOPPIX_V5.1.0CD-2006-12-30-EN.iso -m 384 -pidfile
> $DIR/virt1-knoppix.pid -smp 1 -no-kqemu -clock rtc -vnc :9

Ehm:
1. can you simply use SDL output instead of VNC?
2. what if you don't use -localtime? just courious...

> ==
> $ cat /proc/sys/dev/rtc/max-user-freq
> ==
> 4096
> ==

ehm...I think 1024 is enough for most cases..

> $ uname -a
> ==
> Linux *** 2.6.18-5-amd64 #1 SMP Sat Dec 22 20:43:59 UTC 2007 x86_64
> GNU/Linux
> ==

is that kernel version of the host? can you upgrade it ? let's say to
the latest 2.6.24?

PS: could you try KVM too? but ehm...well, sounds like you don't have
VT enabled Intel processor or SVM enabled AMD processor. So, if you
indeed have one...try KVM..

regards,

Mulyadi.

RE: [kvm-ia64-devel] [Qemu-devel] Re: [kvm-devel] [PATCH] MakingSLIRP code more 64-bit clean

[Zhang, Xiantao]

Blue Swirl wrote:
> On 1/30/08, Scott Pakin <[EMAIL PROTECTED]> wrote:
>> Zhang, Xiantao wrote:
>>> Scott Pakin wrote:
 The attached patch corrects a bug in qemu/slirp/tcp_var.h that
 defines the seg_next field in struct tcpcb to be 32 bits wide
 regardless of 32/64-bitness.  seg_next is assigned a pointer value
 in qemu/slirp/tcp_subr.c, then cast back to a pointer in
 qemu/slirp/tcp_input.c and dereferenced.  That produces a SIGSEGV
 on my system.
>>> 
>>> 
>>> I still hit it on IA64 platform with your patch, once configured
>>> with slirp.
>> 
>> Okay, here's a more thorough patch that fixes *all* of the "cast
>> from/to pointer to/from integer of a different size" mistakes that
>> gcc warns about.  Does it also solve the SIGSEGV problem on IA64?
> 
> The SLIRP code is much, much more subtle than that. Please see this
> thread:
> http://lists.gnu.org/archive/html/qemu-devel/2007-10/msg00542.html 

Got it. Thank you! 
Xiantao

[Qemu-devel] Re: [kvm-devel] [PATCH] Making SLIRP code more 64-bit clean

[Scott Pakin]

I just noticed that my previous patch hit one of the subtleties that
Blue Swirl warned about.  Changing caddr32_t causes the IP header and
IP header overlay to be different sizes, which essentially breaks
networking altogether.

I humbly offer the following patch, which fixes only the "easy" 32/64-bit
bugs but leaves the tricky 32/64-bit bugs in the IP header processing
intact for someone abler than I to fix.

-- Scott

= BEGIN tcp_int32_pointer_cast_no_caddr.patch ==
diff -Naur kvm-60-ORIG/qemu/exec-all.h kvm-60/qemu/exec-all.h
--- kvm-60-ORIG/qemu/exec-all.h 2008-01-20 05:35:04.0 -0700
+++ kvm-60/qemu/exec-all.h  2008-01-31 17:36:34.0 -0700
@@ -169,7 +169,7 @@
 #ifdef USE_DIRECT_JUMP
 uint16_t tb_jmp_offset[4]; /* offset of jump instruction */
 #else
-uint32_t tb_next[2]; /* address of jump generated code */
+uintptr_t tb_next[2]; /* address of jump generated code */
 #endif
 /* list of TBs jumping to this one. This is a circular list using
the two least significant bits of the pointers to tell what is
diff -Naur kvm-60-ORIG/qemu/slirp/ip.h kvm-60/qemu/slirp/ip.h
--- kvm-60-ORIG/qemu/slirp/ip.h 2008-01-20 05:35:04.0 -0700
+++ kvm-60/qemu/slirp/ip.h  2008-01-31 17:29:28.0 -0700
@@ -193,13 +193,8 @@
 #endif
 #endif

-#if SIZEOF_CHAR_P == 4
 typedef struct ipq *ipqp_32;
 typedef struct ipasfrag *ipasfragp_32;
-#else
-typedef caddr32_t ipqp_32;
-typedef caddr32_t ipasfragp_32;
-#endif

 /*
  * Overlay for ip header used by other protocols (tcp, udp).
diff -Naur kvm-60-ORIG/qemu/slirp/misc.c kvm-60/qemu/slirp/misc.c
--- kvm-60-ORIG/qemu/slirp/misc.c   2008-01-20 05:35:04.0 -0700
+++ kvm-60/qemu/slirp/misc.c2008-01-31 17:30:14.0 -0700
@@ -97,39 +97,6 @@
 our_addr.s_addr = loopback_addr.s_addr;
 }

-#if SIZEOF_CHAR_P == 8
-
-struct quehead_32 {
-   u_int32_t qh_link;
-   u_int32_t qh_rlink;
-};
-
-inline void
-insque_32(a, b)
-   void *a;
-   void *b;
-{
-   register struct quehead_32 *element = (struct quehead_32 *) a;
-   register struct quehead_32 *head = (struct quehead_32 *) b;
-   element->qh_link = head->qh_link;
-   head->qh_link = (u_int32_t)element;
-   element->qh_rlink = (u_int32_t)head;
-   ((struct quehead_32 *)(element->qh_link))->qh_rlink
-   = (u_int32_t)element;
-}
-
-inline void
-remque_32(a)
-   void *a;
-{
-   register struct quehead_32 *element = (struct quehead_32 *) a;
-   ((struct quehead_32 *)(element->qh_link))->qh_rlink = element->qh_rlink;
-   ((struct quehead_32 *)(element->qh_rlink))->qh_link = element->qh_link;
-   element->qh_rlink = 0;
-}
-
-#endif /* SIZEOF_CHAR_P == 8 */
-
 struct quehead {
struct quehead *qh_link;
struct quehead *qh_rlink;
diff -Naur kvm-60-ORIG/qemu/slirp/slirp.h kvm-60/qemu/slirp/slirp.h
--- kvm-60-ORIG/qemu/slirp/slirp.h  2008-01-20 05:35:04.0 -0700
+++ kvm-60/qemu/slirp/slirp.h   2008-01-31 17:30:58.0 -0700
@@ -265,13 +265,8 @@

 void lprint _P((const char *, ...));

-#if SIZEOF_CHAR_P == 4
-# define insque_32 insque
-# define remque_32 remque
-#else
- inline void insque_32 _P((void *, void *));
- inline void remque_32 _P((void *));
-#endif
+#define insque_32 insque
+#define remque_32 remque

 #ifndef _WIN32
 #include 
diff -Naur kvm-60-ORIG/qemu/slirp/tcp_var.h kvm-60/qemu/slirp/tcp_var.h
--- kvm-60-ORIG/qemu/slirp/tcp_var.h2008-01-20 05:35:04.0 -0700
+++ kvm-60/qemu/slirp/tcp_var.h 2008-01-31 17:35:03.0 -0700
@@ -40,11 +40,7 @@
 #include "tcpip.h"
 #include "tcp_timer.h"

-#if SIZEOF_CHAR_P == 4
- typedef struct tcpiphdr *tcpiphdrp_32;
-#else
- typedef u_int32_t tcpiphdrp_32;
-#endif
+typedef struct tcpiphdr *tcpiphdrp_32;

 /*
  * Tcp control block, one per tcp; fields:
@@ -178,11 +174,7 @@
  * port numbers (which are no longer needed once we've located the
  * tcpcb) are overlayed with an mbuf pointer.
  */
-#if SIZEOF_CHAR_P == 4
 typedef struct mbuf *mbufp_32;
-#else
-typedef u_int32_t mbufp_32;
-#endif
 #define REASS_MBUF(ti) (*(mbufp_32 *)&((ti)->ti_t))

 #ifdef LOG_ENABLED
== END tcp_int32_pointer_cast_no_caddr.patch ===

[Qemu-devel] Re: [PATCH 4/6] Tell BIOS about the number of CPUs

[Paul Brook]

> > Are the CMOS contents documented anywhere?
>
> No, but if you have a suggestion of where to document them, I'll add
> documentation.

I suggest in or with the BIOS sources.
As we're using a common BIOS it seems a good idea to make sure this kind of 
things is coordinated.

Paul

[Qemu-devel] Re: [PATCH 1/6] Use correct types to enable > 2G support

[Anthony Liguori]

Paul Brook wrote:

+#define PHYS_RAM_MAX_SIZE (2047 * 1024 * 1024 * 1024ULL)


This seems fairly arbitrary. Why? Any limit is certainly target specific.
  

On a 32-bit host, a 2GB limit is pretty reasonable since you're limited
in virtual address space.  On a 64-bit host, there isn't this
fundamental limit.  If a target may have it's own limit but there is
definitely a host imposed limit.

2047GBs is a somewhat arbitrary limit though for 64-bit hosts.  If you
have a more logical suggestion, I'll happily change it.



Don't have a limit at all.

The reason we have the current 31-bit limit is because qemu is/was known to 
use a signed int do hold the size. With your code 64-bit hosts should be able 
to handle anything atoi can parse.


As mentioned on IRC, I also noticed that ram_save hasn't been updated.
  


Okay, I'll update both of these.

Regards,

Anthony Liguori


Paul
  

[Qemu-devel] Re: [PATCH 1/6] Use correct types to enable > 2G support

[Paul Brook]

> >> +#define PHYS_RAM_MAX_SIZE (2047 * 1024 * 1024 * 1024ULL)
> >
> > This seems fairly arbitrary. Why? Any limit is certainly target specific.
>
> On a 32-bit host, a 2GB limit is pretty reasonable since you're limited
> in virtual address space.  On a 64-bit host, there isn't this
> fundamental limit.  If a target may have it's own limit but there is
> definitely a host imposed limit.
>
> 2047GBs is a somewhat arbitrary limit though for 64-bit hosts.  If you
> have a more logical suggestion, I'll happily change it.

Don't have a limit at all.

The reason we have the current 31-bit limit is because qemu is/was known to 
use a signed int do hold the size. With your code 64-bit hosts should be able 
to handle anything atoi can parse.

As mentioned on IRC, I also noticed that ram_save hasn't been updated.

Paul

Re: [Qemu-devel] [patch] cocoa.m - Core Graphics support

[Jamie Lokier]

Anthony Liguori wrote:
> >That's 16MB/frame on an Apple Cinema display at 32bpp, which is
> >0.5GB/sec.  Not too much, but not free either :-)
> >  
> 
> But your guest isn't displaying to the entire screen...  I was assuming 
> a 32-pixel height, 1024 pixel wide region.

I don't know about you; I quite like running Qemu in full screen mode
on my biggest screen when I want to do some work in another OS.  (I
don't have a Cinema display, though, it was just to make the point).

But this is not an important thing, let's leave it.

-- Jamie

[Qemu-devel] Re: [PATCH 4/6] Tell BIOS about the number of CPUs

[Anthony Liguori]

Paul Brook wrote:

-cmos_init(ram_size, above_4g_mem_size, boot_device, hd);
+cmos_init(ram_size, above_4g_mem_size, boot_device, hd, smp_cpus);



smp_cpus is a global variable. Why bother passing it around?
  


True, I'll update the patch


Are the CMOS contents documented anywhere?
  


No, but if you have a suggestion of where to document them, I'll add 
documentation.


Regards,

Anthony Liguori


Paul
  

[Qemu-devel] Re: [PATCH 1/6] Use correct types to enable > 2G support

[Anthony Liguori]

Paul Brook wrote:

On Thursday 31 January 2008, 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.



You've still got a fairly random mix of unsigned long, ram_addr_t and 
uint64_t.
  


I wasn't the one that did this work, but we've tested KVM with very 
large amounts of memory (~15GB I believe).  I suspect the changes were 
driven by trial and error.  Perhaps Izik can shed more light on how 
things were changed?



-typedef void QEMUMachineInitFunc(int ram_size, int vga_ram_size,
+typedef void QEMUMachineInitFunc(ram_addr_t ram_size, int vga_ram_size,



This breaks every target except x86.

  


Indeed.  I missed this because it's only a warning since it's just a 
pointer cast.  I'll fix the patch for all the remaining targets.  Thanks!



+if (above_4g_mem_size) {
+rtc_set_memory(s, 0x5b, (unsigned int)above_4g_mem_size >> 16);
+rtc_set_memory(s, 0x5c, (unsigned int)above_4g_mem_size >> 24);
+rtc_set_memory(s, 0x5d, above_4g_mem_size >> 32);



This will cause warnings on 32-bit hosts.
  


Yeah, it needs a (uint64_t), I'll update.


+#define PHYS_RAM_MAX_SIZE (2047 * 1024 * 1024 * 1024ULL)



This seems fairly arbitrary. Why? Any limit is certainly target specific.
  


On a 32-bit host, a 2GB limit is pretty reasonable since you're limited 
in virtual address space.  On a 64-bit host, there isn't this 
fundamental limit.  If a target may have it's own limit but there is 
definitely a host imposed limit.


2047GBs is a somewhat arbitrary limit though for 64-bit hosts.  If you 
have a more logical suggestion, I'll happily change it.


Regards,

Anthony Liguori



Paul
  

[Qemu-devel] Re: [PATCH 4/6] Tell BIOS about the number of CPUs

[Paul Brook]

> -cmos_init(ram_size, above_4g_mem_size, boot_device, hd);
> +cmos_init(ram_size, above_4g_mem_size, boot_device, hd, smp_cpus);

smp_cpus is a global variable. Why bother passing it around?

Are the CMOS contents documented anywhere?

Paul

[Qemu-devel] Re: [PATCH 1/6] Use correct types to enable > 2G support

[Paul Brook]

On Thursday 31 January 2008, 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.

You've still got a fairly random mix of unsigned long, ram_addr_t and 
uint64_t.

> -typedef void QEMUMachineInitFunc(int ram_size, int vga_ram_size,
> +typedef void QEMUMachineInitFunc(ram_addr_t ram_size, int vga_ram_size,

This breaks every target except x86.

> +    if (above_4g_mem_size) {
> +        rtc_set_memory(s, 0x5b, (unsigned int)above_4g_mem_size >> 16);
> +        rtc_set_memory(s, 0x5c, (unsigned int)above_4g_mem_size >> 24);
> +        rtc_set_memory(s, 0x5d, above_4g_mem_size >> 32);

This will cause warnings on 32-bit hosts.

> +if (ram_size >= 0xe000 ) {
> +above_4g_mem_size = ram_size - 0xe000;
> +ram_size = 0xe000;
> +}

I'm fairly sure this will break the VMware VGA adapter:

> pci_vmsvga_init(pci_bus, ds, phys_ram_base + ram_size,
> ram_size, vga_ram_size);

> +#define PHYS_RAM_MAX_SIZE (2047 * 1024 * 1024 * 1024ULL)

This seems fairly arbitrary. Why? Any limit is certainly target specific.

Paul

Re: [Qemu-devel] [patch] cocoa.m - Core Graphics support

[Anthony Liguori]

Jamie Lokier wrote:

Anthony Liguori wrote:
  
VGA framebuffer operations come in as memory operations.  They're 
tracked by watching what memory gets dirtied.  This can only operate at 
a page-granularity so this results in scan-line granularity updates.  
The VNC front-end goes to great lengths to keep a shadowed framebuffer 
and reduce these updates to a smaller update region.  You could possibly 
look at refactoring that code.  However...



That update region code should probably be moved to something generic
and made into a generic display option.

Reducing update region is logically orthogonal, and could work with
any update method (e.g. local X11, remote X11, local X11-OpenGL,
remote X11-OpenGL, SDL etc.).  With some of those, for some people
(especially some but not all remote setups) it might be worth it.

  
I would be amazed if screen updates on OS X are so slow that it would 
make a difference if updates are in scanline granularities.  The copying 
latency is nothing compared to the other latencies in QEMU.  A modern 
processor can move memory at an extremely high speed.


At a refresh rate of 30 times per second, this is only ~4MB of data for 
mouse movements.  A typical processor can easily handle many GB of data 
per second.



That's 16MB/frame on an Apple Cinema display at 32bpp, which is
0.5GB/sec.  Not too much, but not free either :-)
  


But your guest isn't displaying to the entire screen...  I was assuming 
a 32-pixel height, 1024 pixel wide region.


Regards,

Anthony Liguori


-- Jamie


  

Re: [qemu-devel] [PATCH 0/6] Support for the Kernel Virtual Machine interface

[Anthony Liguori]

FYI, for the new files introduced, Avi should be following up with a 
patch to add Copyrights to the files.  They will be licensed under the GPL.


Regards,

Anthony Liguori

Anthony Liguori wrote:

KVM is a Linux interface for providing userspace interfaces for accelerated
virtualization.  It has been included since 2.6.20 and supports Intel VT and
AMD-V.  Ports are under way for ia64, embedded PowerPC, and s390.

This set of patches provide basic support for KVM in QEMU.  It does not include
all of the changes in the KVM QEMU branch (such as virtio, live migration,
extboot, etc).  However, if we can get these first portions merged, I will
follow up with the remainder of the changes and I believe we can be fully
merged in the very near future.

The first 5 patches of this series are not KVM specific but are critical fixes
for KVM to be functional.  The 6th patch provides KVM support.  The goal in
providing KVM support is to make sure that when KVM support is not compiled in,
the code paths aren't changed at all.  I hope this makes it very easy to merge.

KVM moves very quickly, so I'd appreciate if these patches can be reviewed as
soon as possible as it's going to be tough to keep them in sync with the main
KVM tree while they're out of tree.

To enable KVM support, you have to have to libkvm installed.  You should also
explicitly specify the location of your kernel tree (with KVM headers) with the
--kernel-path option.  We will improve libkvm such that this isn't required in
future versions.

KVM also has an enhanced Bochs BIOS.  I've tested these patches with out it and
it's not strictly necessary for basic functionality.  I would recommend pulling
in a copy of it though as it has useful fixes even in the absence of KVM.

A very large number of people have contributed to these patches with Avi Kivity
being the main developer of this support.  For a full listing of contributers,
please consult the KVM ChangeLog[1].

[1] http://kvm.qumranet.com/kvmwiki/ChangeLog

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kvm-devel
  

[Qemu-devel] [PATCH 4/6] Tell BIOS about the number of CPUs

[Anthony Liguori]

Previously, the BIOS would probe the CPUs for SMP guests.  This tends to be
very unreliably because of startup timing issues.  By passing the number of
CPUs in the CMOS, the BIOS can detect the number of CPUs much more reliably.

Index: qemu/hw/pc.c
===
--- qemu.orig/hw/pc.c   2008-01-30 13:47:37.0 -0600
+++ qemu/hw/pc.c2008-01-30 13:47:40.0 -0600
@@ -182,7 +182,8 @@
 
 /* hd_table must contain 4 block drivers */
 static void cmos_init(ram_addr_t ram_size, ram_addr_t above_4g_mem_size,
- const char *boot_device, BlockDriverState **hd_table)
+ const char *boot_device, BlockDriverState **hd_table,
+ int smp_cpus)
 {
 RTCState *s = rtc_state;
 int nbds, bds[3] = { 0, };
@@ -210,6 +211,7 @@
 rtc_set_memory(s, 0x5c, (unsigned int)above_4g_mem_size >> 24);
 rtc_set_memory(s, 0x5d, above_4g_mem_size >> 32);
 }
+rtc_set_memory(s, 0x5f, smp_cpus - 1);
 
 if (ram_size > (16 * 1024 * 1024))
 val = (ram_size / 65536) - ((16 * 1024 * 1024) / 65536);
@@ -989,7 +991,7 @@
 }
 floppy_controller = fdctrl_init(i8259[6], 2, 0, 0x3f0, fd);
 
-cmos_init(ram_size, above_4g_mem_size, boot_device, hd);
+cmos_init(ram_size, above_4g_mem_size, boot_device, hd, smp_cpus);
 
 if (pci_enabled && usb_enabled) {
 usb_uhci_piix3_init(pci_bus, piix3_devfn + 2);

[Qemu-devel] [PATCH 2/6] SCI fixes

[Anthony Liguori]

KVM supports the ability to use ACPI to shutdown guests.  In order to enable
this requires some fixes to be able to generate the SCI interrupt and the
appropriate plumbing.

Index: qemu/hw/acpi.c
===
--- qemu.orig/hw/acpi.c 2008-01-30 13:47:00.0 -0600
+++ qemu/hw/acpi.c  2008-01-30 13:47:37.0 -0600
@@ -49,6 +49,7 @@
 uint8_t smb_data1;
 uint8_t smb_data[32];
 uint8_t smb_index;
+qemu_irq irq;
 } PIIX4PMState;
 
 #define RTC_EN (1 << 10)
@@ -71,6 +72,8 @@
 #define SMBHSTDAT1 0x06
 #define SMBBLKDAT 0x07
 
+PIIX4PMState *pm_state;
+
 static uint32_t get_pmtmr(PIIX4PMState *s)
 {
 uint32_t d;
@@ -97,11 +100,12 @@
 pmsts = get_pmsts(s);
 sci_level = (((pmsts & s->pmen) &
   (RTC_EN | PWRBTN_EN | GBL_EN | TMROF_EN)) != 0);
-qemu_set_irq(s->dev.irq[0], sci_level);
+qemu_set_irq(s->irq, sci_level);
 /* schedule a timer interruption if needed */
 if ((s->pmen & TMROF_EN) && !(pmsts & TMROF_EN)) {
 expire_time = muldiv64(s->tmr_overflow_time, ticks_per_sec, PM_FREQ);
 qemu_mod_timer(s->tmr_timer, expire_time);
+s->tmr_overflow_time += 0x80;
 } else {
 qemu_del_timer(s->tmr_timer);
 }
@@ -467,7 +471,8 @@
 return 0;
 }
 
-i2c_bus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base)
+i2c_bus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base,
+   qemu_irq sci_irq)
 {
 PIIX4PMState *s;
 uint8_t *pci_conf;
@@ -475,6 +480,7 @@
 s = (PIIX4PMState *)pci_register_device(bus,
  "PM", sizeof(PIIX4PMState),
  devfn, NULL, pm_write_config);
+pm_state = s;
 pci_conf = s->dev.config;
 pci_conf[0x00] = 0x86;
 pci_conf[0x01] = 0x80;
@@ -514,5 +520,16 @@
 register_savevm("piix4_pm", 0, 1, pm_save, pm_load, s);
 
 s->smbus = i2c_init_bus();
+s->irq = sci_irq;
 return s->smbus;
 }
+
+#if defined(TARGET_I386)
+void qemu_system_powerdown(void)
+{
+if(pm_state->pmen & PWRBTN_EN) {
+pm_state->pmsts |= PWRBTN_EN;
+   pm_update_sci(pm_state);
+}
+}
+#endif
Index: qemu/hw/mips_malta.c
===
--- qemu.orig/hw/mips_malta.c   2008-01-30 13:47:00.0 -0600
+++ qemu/hw/mips_malta.c2008-01-30 13:47:37.0 -0600
@@ -905,7 +905,7 @@
 piix4_devfn = piix4_init(pci_bus, 80);
 pci_piix4_ide_init(pci_bus, hd, piix4_devfn + 1, i8259);
 usb_uhci_piix4_init(pci_bus, piix4_devfn + 2);
-smbus = piix4_pm_init(pci_bus, piix4_devfn + 3, 0x1100);
+smbus = piix4_pm_init(pci_bus, piix4_devfn + 3, 0x1100, i8259[9]);
 eeprom_buf = qemu_mallocz(8 * 256); /* XXX: make this persistent */
 for (i = 0; i < 8; i++) {
 /* TODO: Populate SPD eeprom data.  */
Index: qemu/hw/pc.c
===
--- qemu.orig/hw/pc.c   2008-01-30 13:47:31.0 -0600
+++ qemu/hw/pc.c2008-01-30 13:47:37.0 -0600
@@ -1000,7 +1000,7 @@
 i2c_bus *smbus;
 
 /* TODO: Populate SPD eeprom data.  */
-smbus = piix4_pm_init(pci_bus, piix3_devfn + 3, 0xb100);
+smbus = piix4_pm_init(pci_bus, piix3_devfn + 3, 0xb100, i8259[9]);
 for (i = 0; i < 8; i++) {
 smbus_eeprom_device_init(smbus, 0x50 + i, eeprom_buf + (i * 256));
 }
Index: qemu/hw/pc.h
===
--- qemu.orig/hw/pc.h   2008-01-30 13:47:00.0 -0600
+++ qemu/hw/pc.h2008-01-30 13:47:37.0 -0600
@@ -88,7 +88,8 @@
 
 /* acpi.c */
 extern int acpi_enabled;
-i2c_bus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base);
+i2c_bus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base,
+   qemu_irq sci_irq);
 void piix4_smbus_register_device(SMBusDevice *dev, uint8_t addr);
 void acpi_bios_init(void);
 
Index: qemu/hw/piix_pci.c
===
--- qemu.orig/hw/piix_pci.c 2008-01-30 13:47:00.0 -0600
+++ qemu/hw/piix_pci.c  2008-01-30 13:47:37.0 -0600
@@ -220,7 +220,6 @@
 {
 int i, pic_irq, pic_level;
 
-piix3_dev->config[0x60 + irq_num] &= ~0x80;   // enable bit
 pci_irq_levels[irq_num] = level;
 
 /* now we change the pic irq level according to the piix irq mappings */
Index: qemu/sysemu.h
===
--- qemu.orig/sysemu.h  2008-01-30 13:47:31.0 -0600
+++ qemu/sysemu.h   2008-01-30 13:47:37.0 -0600
@@ -30,12 +30,16 @@
 void qemu_system_reset_request(void);
 void qemu_system_shutdown_request(void);
 void qemu_system_powerdown_request(void);
-#if !defined(TARGET_SPARC)
+int qemu_shutdown_requested(void);
+int qemu_reset_requested(void);
+int qemu_powerdown_requested(void);
+#if 

[Qemu-devel] [PATCH 3/6] Fix daemonize options

[Anthony Liguori]

The -daemonize option is too restrictive when using with SDL.  It also switches
the working directory to / too early which causes block devices with a relative
path to fail.

The -daemonize option is needed for my regression testing so I've included this
patch in the series.


Index: qemu/vl.c
===
--- qemu.orig/vl.c  2008-01-30 13:47:37.0 -0600
+++ qemu/vl.c   2008-01-30 13:47:39.0 -0600
@@ -8766,11 +8766,6 @@
 }
 
 #ifndef _WIN32
-if (daemonize && !nographic && vnc_display == NULL) {
-   fprintf(stderr, "Can only daemonize if using -nographic or -vnc\n");
-   daemonize = 0;
-}
-
 if (daemonize) {
pid_t pid;
 
@@ -8808,7 +8803,6 @@
exit(1);
 
umask(027);
-   chdir("/");
 
 signal(SIGTSTP, SIG_IGN);
 signal(SIGTTOU, SIG_IGN);
@@ -9067,6 +9061,7 @@
if (len != 1)
exit(1);
 
+   chdir("/");
TFR(fd = open("/dev/null", O_RDWR));
if (fd == -1)
exit(1);

[Qemu-devel] [PATCH 1/6] Use correct types to enable > 2G support

[Anthony Liguori]

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.

Index: qemu/cpu-all.h
===
--- qemu.orig/cpu-all.h 2008-01-30 13:47:00.0 -0600
+++ qemu/cpu-all.h  2008-01-30 13:47:31.0 -0600
@@ -695,7 +695,7 @@
 
 /* page related stuff */
 
-#define TARGET_PAGE_SIZE (1 << TARGET_PAGE_BITS)
+#define TARGET_PAGE_SIZE (1ul << TARGET_PAGE_BITS)
 #define TARGET_PAGE_MASK ~(TARGET_PAGE_SIZE - 1)
 #define TARGET_PAGE_ALIGN(addr) (((addr) + TARGET_PAGE_SIZE - 1) & 
TARGET_PAGE_MASK)
 
@@ -816,7 +816,7 @@
 
 /* memory API */
 
-extern int phys_ram_size;
+extern ram_addr_t phys_ram_size;
 extern int phys_ram_fd;
 extern uint8_t *phys_ram_base;
 extern uint8_t *phys_ram_dirty;
@@ -844,7 +844,7 @@
   unsigned long size,
   unsigned long phys_offset);
 uint32_t cpu_get_physical_page_desc(target_phys_addr_t addr);
-ram_addr_t qemu_ram_alloc(unsigned int size);
+ram_addr_t qemu_ram_alloc(unsigned long size);
 void qemu_ram_free(ram_addr_t addr);
 int cpu_register_io_memory(int io_index,
CPUReadMemoryFunc **mem_read,
Index: qemu/exec.c
===
--- qemu.orig/exec.c2008-01-30 13:47:00.0 -0600
+++ qemu/exec.c 2008-01-30 13:47:31.0 -0600
@@ -73,9 +73,11 @@
 #define TARGET_VIRT_ADDR_SPACE_BITS 42
 #elif defined(TARGET_PPC64)
 #define TARGET_PHYS_ADDR_SPACE_BITS 42
-#else
+#elif USE_KQEMU
 /* Note: for compatibility with kqemu, we use 32 bits for x86_64 */
 #define TARGET_PHYS_ADDR_SPACE_BITS 32
+#else
+#define TARGET_PHYS_ADDR_SPACE_BITS 42
 #endif
 
 TranslationBlock tbs[CODE_GEN_MAX_BLOCKS];
@@ -87,7 +89,7 @@
 uint8_t code_gen_buffer[CODE_GEN_BUFFER_SIZE] __attribute__((aligned (32)));
 uint8_t *code_gen_ptr;
 
-int phys_ram_size;
+ram_addr_t phys_ram_size;
 int phys_ram_fd;
 uint8_t *phys_ram_base;
 uint8_t *phys_ram_dirty;
@@ -112,7 +114,7 @@
 
 typedef struct PhysPageDesc {
 /* offset in host memory of the page + io_index in the low 12 bits */
-uint32_t phys_offset;
+ram_addr_t phys_offset;
 } PhysPageDesc;
 
 #define L2_BITS 10
@@ -2083,11 +2085,11 @@
 }
 
 /* XXX: better than nothing */
-ram_addr_t qemu_ram_alloc(unsigned int size)
+ram_addr_t qemu_ram_alloc(unsigned long size)
 {
 ram_addr_t addr;
 if ((phys_ram_alloc_offset + size) >= phys_ram_size) {
-fprintf(stderr, "Not enough memory (requested_size = %u, max memory = 
%d)\n",
+fprintf(stderr, "Not enough memory (requested_size = %lu, max memory = 
%d)\n",
 size, phys_ram_size);
 abort();
 }
Index: qemu/hw/boards.h
===
--- qemu.orig/hw/boards.h   2008-01-30 13:47:00.0 -0600
+++ qemu/hw/boards.h2008-01-30 13:47:31.0 -0600
@@ -3,7 +3,7 @@
 #ifndef HW_BOARDS_H
 #define HW_BOARDS_H
 
-typedef void QEMUMachineInitFunc(int ram_size, int vga_ram_size,
+typedef void QEMUMachineInitFunc(ram_addr_t ram_size, int vga_ram_size,
  const char *boot_device, DisplayState *ds,
  const char *kernel_filename,
  const char *kernel_cmdline,
Index: qemu/hw/pc.c
===
--- qemu.orig/hw/pc.c   2008-01-30 13:47:00.0 -0600
+++ qemu/hw/pc.c2008-01-30 13:47:31.0 -0600
@@ -181,7 +181,8 @@
 }
 
 /* hd_table must contain 4 block drivers */
-static void cmos_init(int ram_size, const char *boot_device, BlockDriverState 
**hd_table)
+static void cmos_init(ram_addr_t ram_size, ram_addr_t above_4g_mem_size,
+ const char *boot_device, BlockDriverState **hd_table)
 {
 RTCState *s = rtc_state;
 int nbds, bds[3] = { 0, };
@@ -204,6 +205,12 @@
 rtc_set_memory(s, 0x30, val);
 rtc_set_memory(s, 0x31, val >> 8);
 
+if (above_4g_mem_size) {
+rtc_set_memory(s, 0x5b, (unsigned int)above_4g_mem_size >> 16);
+rtc_set_memory(s, 0x5c, (unsigned int)above_4g_mem_size >> 24);
+rtc_set_memory(s, 0x5d, above_4g_mem_size >> 32);
+}
+
 if (ram_size > (16 * 1024 * 1024))
 val = (ram_size / 65536) - ((16 * 1024 * 1024) / 65536);
 else
@@ -697,7 +704,7 @@
 }
 
 /* PC hardware initialisation */
-static void pc_init1(int ram_size, int vga_ram_size,
+static void pc_init1(ram_addr_t ram_size, int vga_ram_size,
  const char *boot_device, DisplayState *ds,
  const char *kernel_filename, const char *kernel_cmdline,
  const char *initrd_filename,
@@ -706,6 +713,7 @@
 char buf[1024];
 int ret, linux_boot, i;
 ram

[Qemu-devel] [PATCH 5/6] Refactor option ROM loading

[Anthony Liguori]

KVM requires that any ROM memory be registerd through a second interface.  This
patch refactors the option ROM loading to simplify adding KVM support (which
will follow in the next patch).

Index: qemu/hw/pc.c
===
--- qemu.orig/hw/pc.c   2008-01-30 13:47:40.0 -0600
+++ qemu/hw/pc.c2008-01-30 13:47:41.0 -0600
@@ -704,6 +704,31 @@
 isa_ne2000_init(ne2000_io[nb_ne2k], pic[ne2000_irq[nb_ne2k]], nd);
 nb_ne2k++;
 }
+ 
+static int load_option_rom(const char *filename, int offset)
+{
+ram_addr_t option_rom_offset;
+int size, ret;
+
+size = get_image_size(filename);
+if (size < 0) {
+   fprintf(stderr, "Could not load option rom '%s'\n", filename);
+   exit(1);
+}
+if (size > (0x1 - offset))
+   goto option_rom_error;
+option_rom_offset = qemu_ram_alloc(size);
+ret = load_image(filename, phys_ram_base + option_rom_offset);
+if (ret != size) {
+option_rom_error:
+   fprintf(stderr, "Too many option ROMS\n");
+   exit(1);
+}
+size = (size + 4095) & ~4095;
+cpu_register_physical_memory(0xd + offset,
+size, option_rom_offset | IO_MEM_ROM);
+return size;
+}
 
 /* PC hardware initialisation */
 static void pc_init1(ram_addr_t ram_size, int vga_ram_size,
@@ -716,7 +741,7 @@
 int ret, linux_boot, i;
 ram_addr_t ram_addr, vga_ram_addr, bios_offset, vga_bios_offset;
 ram_addr_t above_4g_mem_size = 0;
-int bios_size, isa_bios_size, vga_bios_size;
+int bios_size, isa_bios_size, vga_bios_size, opt_rom_offset;
 PCIBus *pci_bus;
 int piix3_devfn = -1;
 CPUState *env;
@@ -825,33 +850,9 @@
  isa_bios_size,
  (bios_offset + bios_size - isa_bios_size) | 
IO_MEM_ROM);
 
-{
-ram_addr_t option_rom_offset;
-int size, offset;
-
-offset = 0;
-for (i = 0; i < nb_option_roms; i++) {
-size = get_image_size(option_rom[i]);
-if (size < 0) {
-fprintf(stderr, "Could not load option rom '%s'\n",
-option_rom[i]);
-exit(1);
-}
-if (size > (0x1 - offset))
-goto option_rom_error;
-option_rom_offset = qemu_ram_alloc(size);
-ret = load_image(option_rom[i], phys_ram_base + option_rom_offset);
-if (ret != size) {
-option_rom_error:
-fprintf(stderr, "Too many option ROMS\n");
-exit(1);
-}
-size = (size + 4095) & ~4095;
-cpu_register_physical_memory(0xd + offset,
- size, option_rom_offset | IO_MEM_ROM);
-offset += size;
-}
-}
+opt_rom_offset = 0;
+for (i = 0; i < nb_option_roms; i++)
+   opt_rom_offset += load_option_rom(option_rom[i], opt_rom_offset);
 
 /* map all the bios at the top of memory */
 cpu_register_physical_memory((uint32_t)(-bios_size),

[Qemu-devel] [PATCH 0/6] Support for the Kernel Virtual Machine interface

[Anthony Liguori]

KVM is a Linux interface for providing userspace interfaces for accelerated
virtualization.  It has been included since 2.6.20 and supports Intel VT and
AMD-V.  Ports are under way for ia64, embedded PowerPC, and s390.

This set of patches provide basic support for KVM in QEMU.  It does not include
all of the changes in the KVM QEMU branch (such as virtio, live migration,
extboot, etc).  However, if we can get these first portions merged, I will
follow up with the remainder of the changes and I believe we can be fully
merged in the very near future.

The first 5 patches of this series are not KVM specific but are critical fixes
for KVM to be functional.  The 6th patch provides KVM support.  The goal in
providing KVM support is to make sure that when KVM support is not compiled in,
the code paths aren't changed at all.  I hope this makes it very easy to merge.

KVM moves very quickly, so I'd appreciate if these patches can be reviewed as
soon as possible as it's going to be tough to keep them in sync with the main
KVM tree while they're out of tree.

To enable KVM support, you have to have to libkvm installed.  You should also
explicitly specify the location of your kernel tree (with KVM headers) with the
--kernel-path option.  We will improve libkvm such that this isn't required in
future versions.

KVM also has an enhanced Bochs BIOS.  I've tested these patches with out it and
it's not strictly necessary for basic functionality.  I would recommend pulling
in a copy of it though as it has useful fixes even in the absence of KVM.

A very large number of people have contributed to these patches with Avi Kivity
being the main developer of this support.  For a full listing of contributers,
please consult the KVM ChangeLog[1].

[1] http://kvm.qumranet.com/kvmwiki/ChangeLog

Re: [Qemu-devel] using actual PPC ROM?

[Markus Hitter]

Am 31.01.2008 um 16:41 schrieb C.W. Betts:


is it possible to use an actual PowerPC ROM in qemu-system-ppc?


This question pops up about once a month, so several people are  
interested in this. AFAIK, the current answer is:


"No, but patches are welcome."


If not, why isn't it?


It needs enthusiasm to debug something you have no sources or  
documentation for. Especially as an almost-working open source  
alternative exists.



Markus

- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/

[Qemu-devel] Re: [kvm-devel] [PATCH] Making SLIRP code more 64-bit clean

[Scott Pakin]

Zhang, Xiantao wrote:

Unfortunately, it can's apply on tip. Could you attach the diff ?


It works for me:

$ git clone git://git.kernel.org/pub/scm/virt/kvm/kvm-userspace.git
remote: Generating pack...
remote: Done counting 37449 objects.
remote: Deltifying 37449 objects...
remote:  100% (37449/37449) done
Indexing 37449 objects.
remote: Total 37449 (delta 24712), reused 37189 (delta 24506)
 100% (37449/37449) done
Resolving 24712 deltas.
 100% (24712/24712) done
Checking files out...
 100% (948/948) done
$ cd kvm-userspace
$ patch -p1 < ~/tcp_int32_pointer_cast.patch
patching file qemu/exec-all.h
patching file qemu/slirp/ip.h
patching file qemu/slirp/misc.c
patching file qemu/slirp/slirp.h
patching file qemu/slirp/tcp_var.h
$

-- Scott

[Qemu-devel] using actual PPC ROM?

[C.W. Betts]

is it possible to use an actual PowerPC ROM in qemu-system-ppc?  If so, what 
would be the minimum Mac ROM that would be used (I'm guessing the blue and 
white G3)? If not, why isn't it?

Re: [Qemu-devel] [PATCH] x86 Multiboot support (extended)

[Alexander Graf]

On Jan 31, 2008, at 10:58 AM, Kevin Wolf wrote:


Hi,

I like this idea. When I just tried to load my multiboot kernel it
failed, though, because of the following piece of code:

+// XXX: multiboot header may be within the first 8192 bytes,  
but header

+//  is only the first 1024
+
+// Ok, let's see if it is a multiboot image
+for(i=0; i<(256 - 12); i+=4) { // the header is 12x32bit long
+if(ldl_p(header+i) == 0x1BADB002) {


I wonder if there is any reason why you didn't just replace the 1024  
by

8192 in load_linux but added an XXX. Would this cause any problems I
missed? With this change and replacing 256 by 8192 in the above code  
it

works for my kernel, too.

Anyway, I think the for condition should be i < 4 * (256 - 12), even
without changing the 1024.


This version should fix the long header issue. I made the linux loader  
fetch the first 8kb as header, so multiboot can search through all  
necessary data.


I also implemented module parameters. Kevin needed this to boot a  
homebrew kernel. You can now pass commandline parameters to the  
multiboot modules by adding them after the filename, seperated through  
a space. This is the very same approach grub takes.


To boot a xen kernel you would give a command line like this:

qemu -hda image -kernel xen -initrd "vmlinux-xen root=/dev/hda,initrd- 
xen"


This way the vmlinux module gets the command line parameter "root=/dev/ 
hda".


Regards,

Alex

multiboot.new.patch
Description: Binary data

[Qemu-devel] [PATCH] Be consistent in -clock parameter

[Hervé Poussineau]

Hi,

-soundhw, -M, -cpu, -d, -translation options use the '?' to display the 
list of possibilities, whereas -clock uses 'help'. Change it to be 
consistent.
Display also the list of available sources if no valid clock name has 
been specified.
Index: vl.c
===
RCS file: /sources/qemu/qemu/vl.c,v
retrieving revision 1.401
diff -u -r1.401 vl.c
--- vl.c23 Jan 2008 19:01:12 -  1.401
+++ vl.c31 Jan 2008 16:11:12 -
@@ -917,7 +917,7 @@
 char *arg;
 char *name;
 
-if (!strcmp(opt, "help")) {
+if (!strcmp(opt, "?")) {
 show_available_alarms();
 exit(0);
 }
@@ -956,13 +956,13 @@
 free(arg);
 
 if (cur) {
-   /* Disable remaining timers */
+/* Disable remaining timers */
 for (i = cur; i < count; i++)
 alarm_timers[i].name = NULL;
+} else {
+show_available_alarms();
+exit(1);
 }
-
-/* debug */
-show_available_alarms();
 }
 
 QEMUClock *rt_clock;
@@ -7662,7 +7662,7 @@
"-prom-env variable=value  set OpenBIOS nvram variables\n"
 #endif
"-clock  force the use of the given methods for timer 
alarm.\n"
-   "To see what timers are available use -clock help\n"
+   "To see what timers are available use -clock ?\n"
"-startdate  select initial date of the Qemu clock\n"
"-translation setting1,... configures code translation\n"
"(use -translation ? for a list of settings)\n"

Re: [Qemu-devel] QEMU and gdb

[Pierre Ficheux]

Thiemo Seufer a écrit :


FWIW, I had a similiar problem with QEMU 0.9.0 on PPC/Linux host.
It went away at some point before 0.9.1, I don't remember more details.


Have tested with 0.9.1 with same pb. I work with FC5 may be it's a 
distro pb.


Thx.



Thiemo





--
Pierre FICHEUX -/- CTO OW/OS4I, France -\- [EMAIL PROTECTED]
 http://www.os4i.com
 http://www.ficheux.org
I would love to change the world, but they won't give me the source code

[Qemu-devel] [PATCH 4/4] Mac OS X generic support

[Alexander Graf]

This patch implements Mac OS X specific parts that are necessary to  
get i386 and x86_64 versions of qemu working. Since both hosts need  
this patch, I seperated it from the architecture specific ones.


It does:

- not force always_inline
- only define [u]intXX types if they are not already defined
- nullify spin-functions using #define instead of inline function


qemu-mac-generic.patch
Description: Binary data

[Qemu-devel] [PATCH 3/4] Mac OS X i386 support

[Alexander Graf]

This patch implements Mac OS X specific parts that are necessary to  
get i386 versions of qemu working.


It does:

- make the GOTO_TB macro more portable


qemu-mac-i386.patch
Description: Binary data

[Qemu-devel] [PATCH 1/4] dyngen Mach-O support for i386 and x86_64

[Alexander Graf]

This patch extends the existing support for the Mach-O binary format  
in dyngen from PowerPC to PowerPC, i386 and x86_64.

qemu-macho.patch
Description: Binary data

[Qemu-devel] [PATCH 2/4] Mac OS X x86_64 support

[Alexander Graf]

This patch implements Mac OS X specific parts that are necessary to  
get x86_64 versions of qemu working.


It does:

- add x86_64 detection to configure
- add -fomit-frame-pointer if available
- set the pagezero size to <4GB, so 32bit lea still works
- fix redeclarations of int64_t and uint64_t
- add direct jump support for x86_64


qemu-mac-x86_64.patch
Description: Binary data

[Qemu-devel] [PATCH 0/4] Intel Mac OS X Host support

[Alexander Graf]

Hi,

supporting Mac OS X on Intel has been a long standing issue. The Q  
project has done a fabulous job maintaining patches that make things  
work for i386 Mac OS X, but do invasive changes to qemu internals.


This set of patches attempts to make Mac OS X host support as  
compatible as possible to the existing Linux host and PowerPC Mac OS X  
support. Of course this means, that as long as Linux gcc4 support is  
broken, it won't work on Mac OS X either. Nevertheless all changes  
necessary to support the binary format (Mach-O) and several other  
minor issues that are Mac specific can be easily added to the existing  
code base without harming other platforms.


This way people who want to run qemu on Mac OS X only have to maintain  
gcc4 patches and no Apple specific ones.


Please comment on these patches. Commits are welcome too.

Regards,

Alex

Re: [Qemu-devel] QEMU and gdb

[Thiemo Seufer]

Jan Kiszka wrote:
> Pierre Ficheux wrote:
> > Hi all,
> > 
> > I would like to debug QEMU with gdb. When starting qemu (x86) inside
> > gdb, SDL window never appears, it there a way to fix it ?
> 
> I dare to say your local environment is borken, not qemu :->. At least
> its not a generic issue (works fine here: qemu-cvs, built against
> openSUSE 10.3 devel packages)

FWIW, I had a similiar problem with QEMU 0.9.0 on PPC/Linux host.
It went away at some point before 0.9.1, I don't remember more details.


Thiemo

[Qemu-devel] qemu/tests test-i386-code16.S

[Fabrice Bellard]

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=qemu&r1=1.5&r2=1.6

[Qemu-devel] qemu/tests Makefile

[Fabrice Bellard]

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

[Qemu-devel] qemu/tests test-i386.c

[Fabrice Bellard]

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.c?cvsroot=qemu&r1=1.56&r2=1.57

Re: [Qemu-devel] QEMU and gdb

[Jan Kiszka]

Pierre Ficheux wrote:
> Hi all,
> 
> I would like to debug QEMU with gdb. When starting qemu (x86) inside
> gdb, SDL window never appears, it there a way to fix it ?

I dare to say your local environment is borken, not qemu :->. At least
its not a generic issue (works fine here: qemu-cvs, built against
openSUSE 10.3 devel packages)

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

[Qemu-devel] Qemulator

[rainer haage]

Hello!

You might be interested to add a link to the qemulator GUI on the qemu 
homepage. It's now an official part of the Ubuntu universe packages and it's 
also in debian unstable and testing.

Best regards

rainer

-- 
rainer haage - Developer

http://qemulator.createweb.de
[EMAIL PROTECTED]

createweb home:
http://www.createweb.de

[Qemu-devel] More about slow clock in guest OS

[Sergey Bychkov]

- Original Message - 
From: "Mulyadi Santosa" <[EMAIL PROTECTED]>

To: 
Sent: 26.01.2008 16:25
Subject: Re: [Qemu-devel] Slow clock in guest OS


Sorry, did You mean "http://fabrice.bellard.free.fr/qemu/qemu-tech.html"; 
or

what?


yep...that's the one...


As I can see, this document anything about what to do if qemu hung :)

After some investigations I can say that with the latest (2008/01/30) qemu 
from cvs, compiled with gcc-3.4 on linux x86_64 host, guest OS win2k3 works 
not too good.
With "-clock dynticks" clock in OS is very slow - and windows time server 
can't adjust.
With "-clock rtc" hung periodically - for up to 5 minutes, 300 seconds. This 
could happen at bootstrap - when no OS, only BIOS. Then it resumes and works 
for some random period of time, then hangs again, and so on. This behaviour 
doesn't depend on guest OS, and was reproduced with Knoppix live CD. Note 
that host should be periodically busy executing something like torrent 
client.


Details and startup scripts:

$ cat knoppix-qemu-nographic.sh
==
QEMU=$HOME/bin/qemu-system-x86_64
[ -x "$QEMU" ] || QEMU=/usr/bin/qemu-system-x86_64
sudo modprobe kqemu
echo will use executable $QEMU
DIR=`dirname $0`
[ -z "$DIR" -o "$DIR" == "." ] && DIR=`pwd`
echo DIR is $DIR
PREV_RTC_FREQ=`cat /proc/sys/dev/rtc/max-user-freq`
[ "$PREV_RTC_FREQ" -ge "1024" ] || echo 'WARN: RTC FREQ too slow:' 
$PREV_RTC_FREQ
sudo $QEMU -net nic,model=rtl8139,macaddr=52:54:00:80:80:01 -net 
tap,script=$DIR/qemu-ifup-br0,downscript=$DIR/qemu-ifdown-br0 -localtime -cdrom 
/distrib/knoppix/KNOPPIX_V5.1.0CD-2006-12-30-EN.iso -m 384 -pidfile 
$DIR/virt1-knoppix.pid -smp 1 -no-kqemu -clock rtc -vnc :9

==
$ cat qemu-ifup-br0
==
#!/bin/sh

echo Configuring virtual interface $1
if [ "$UID" -eq "0" ]
then
   BRIF=br0
   if brctl addif $BRIF $1
   then
   echo $1 added to $BRIF
   ifconfig $1 0.0.0.0 up
   echo $1 configured for bridge $BRIF
   else
   IP_LOCAL=169.254.1.1
   echo $1 not added to $BRIF
   ifconfig $1 $IP_LOCAL up
   echo $1 configured to $IP_LOCAL \(like autoip\)
   # TODO: try to make real autoip
   fi
else
   echo Will sudo $0
   exec sudo -p "Password for $0:" $0 $*
fi
==
$ cat qemu-ifdown-br0
==
#!/bin/sh
BRIF=br0
ifconfig $1
brctl show $BRIF
brctl showmacs $BRIF
echo Deconfiguring virtual interface $1 will be done automatically
==
Bridge interface should be configured in system
$ cat /etc/network/interfaces
==
#auto eth0 - this interface should not be configured
iface eth0 inet static
...
# The primary network interface - now in bridge mode
auto br0
iface br0 inet static
   bridge_ports eth0
...
==
$ cat /proc/sys/dev/rtc/max-user-freq
==
4096
==
$ uname -a
==
Linux *** 2.6.18-5-amd64 #1 SMP Sat Dec 22 20:43:59 UTC 2007 x86_64 
GNU/Linux

==
$ cat /proc/cpuinfo
==
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 15
model   : 6
model name  :   Intel(R) Pentium(R) D CPU 2.80GHz
stepping: 4
cpu MHz : 2800.000
cache size  : 2048 KB
physical id : 0
siblings: 2
core id : 0
cpu cores   : 2
fpu : yes
fpu_exception   : yes
cpuid level : 6
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm 
constant_tsc pni monitor ds_cpl est cid cx16 xtpr lahf_lm

bogomips: 5633.18
clflush size: 64
cache_alignment : 128
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor   : 1
...
==
$ ~/bin/qemu-system-x86_64
QEMU PC emulator version 0.9.1, Copyright (c) 2003-2008 Fabrice Bellard
...
==

May be somebody will understand what's happen :)

Sergey Bychkow
ICQ: 21014758
FTN: 2:450/118.55 

[Qemu-devel] qemu Makefile Makefile.target configure

[Fabrice Bellard]

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://cvs.savannah.gnu.org/viewcvs/qemu/Makefile?cvsroot=qemu&r1=1.143&r2=1.144
http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemu&r1=1.240&r2=1.241
http://cvs.savannah.gnu.org/viewcvs/qemu/configure?cvsroot=qemu&r1=1.182&r2=1.183

Re: [Qemu-devel] [patch] cocoa.m - Core Graphics support

[Julian Seward]

On Thursday 31 January 2008 10:46, Jamie Lokier wrote:
> Anthony Liguori wrote:
> > VGA framebuffer operations come in as memory operations.  They're
> > tracked by watching what memory gets dirtied.  This can only operate at
> > a page-granularity so this results in scan-line granularity updates.
> > The VNC front-end goes to great lengths to keep a shadowed framebuffer
> > and reduce these updates to a smaller update region.  You could possibly
> > look at refactoring that code.  However...
>
> That update region code should probably be moved to something generic
> and made into a generic display option.
>
> Reducing update region is logically orthogonal, and could work with
> any update method (e.g. local X11, remote X11, local X11-OpenGL,
> remote X11-OpenGL, SDL etc.).  With some of those, for some people
> (especially some but not all remote setups) it might be worth it.

For exactly these reasons I developed a shadow framebuffer patch
which ...

> makes QEMU's graphics emulation much more usable over remote
> X connections, by reducing the amount of data sent to the X server.
> This is particularly noticeable for small display updates, most
> importantly mouse cursor movements, which become faster and so 
> generally make the guest's GUI more pleasant to use.

See
http://lists.gnu.org/archive/html/qemu-devel/2007-03/msg00141.html
for the patch and short associated thread.  It never got included,
though.

J

Re: [Qemu-devel] [patch] cocoa.m - Core Graphics support

[Jamie Lokier]

Anthony Liguori wrote:
> VGA framebuffer operations come in as memory operations.  They're 
> tracked by watching what memory gets dirtied.  This can only operate at 
> a page-granularity so this results in scan-line granularity updates.  
> The VNC front-end goes to great lengths to keep a shadowed framebuffer 
> and reduce these updates to a smaller update region.  You could possibly 
> look at refactoring that code.  However...

That update region code should probably be moved to something generic
and made into a generic display option.

Reducing update region is logically orthogonal, and could work with
any update method (e.g. local X11, remote X11, local X11-OpenGL,
remote X11-OpenGL, SDL etc.).  With some of those, for some people
(especially some but not all remote setups) it might be worth it.

> I would be amazed if screen updates on OS X are so slow that it would 
> make a difference if updates are in scanline granularities.  The copying 
> latency is nothing compared to the other latencies in QEMU.  A modern 
> processor can move memory at an extremely high speed.
> 
> At a refresh rate of 30 times per second, this is only ~4MB of data for 
> mouse movements.  A typical processor can easily handle many GB of data 
> per second.

That's 16MB/frame on an Apple Cinema display at 32bpp, which is
0.5GB/sec.  Not too much, but not free either :-)

-- Jamie

Re: [Qemu-devel] [patch] cocoa.m - Core Graphics support

[Jamie Lokier]

andrzej zaborowski wrote:
> > > Offtoppic about updated regions in Windows: While testing with
> > > Quartzdebug, I realized, that qemu is updating always the whole
> > > screenwidth even if only the mouse is moved... is this a qemu problem,
> > > or is this the default windows behaviour?
> >
> > As far as I remember, this is a QEmu "problem".  It only marks lines as
> > dirty, not pixels.
> 
> In addition lines are not marked dirty because they have a dirty pixel
> in them but because they have a pixel in a dirty page. That means more
> lines are updated than those containing dirty pixels.

However, if there's an emulated "hardware mouse cursor", just moving
the mouse could be optimised to those pixels only.

-- Jamie

[Qemu-devel] qemu i386-vl.ld

[Fabrice Bellard]

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

Re: [Qemu-devel] [PATCH] x86 Multiboot support (extended)

[Alexander Graf]

On Jan 31, 2008, at 10:58 AM, Kevin Wolf wrote:


Hi,

I like this idea. When I just tried to load my multiboot kernel it
failed, though, because of the following piece of code:

+// XXX: multiboot header may be within the first 8192 bytes,  
but header

+//  is only the first 1024
+
+// Ok, let's see if it is a multiboot image
+for(i=0; i<(256 - 12); i+=4) { // the header is 12x32bit long
+if(ldl_p(header+i) == 0x1BADB002) {


I wonder if there is any reason why you didn't just replace the 1024  
by

8192 in load_linux but added an XXX. Would this cause any problems I
missed? With this change and replacing 256 by 8192 in the above code  
it

works for my kernel, too.


The main reason behind it was that I did not want to change currently  
running code if not necessary. If nobody complains about it, I will  
gladly make the Linux loader load 8kb.





Anyway, I think the for condition should be i < 4 * (256 - 12), even
without changing the 1024.


Uhm. Yes. This looks wrong ;-). Thanks for the catch.

Alex

Re: [Qemu-devel] [PATCH] x86 Multiboot support (extended)

[Kevin Wolf]

Hi,

I like this idea. When I just tried to load my multiboot kernel it
failed, though, because of the following piece of code:

> +// XXX: multiboot header may be within the first 8192 bytes, but header
> +//  is only the first 1024
> +
> +// Ok, let's see if it is a multiboot image
> +for(i=0; i<(256 - 12); i+=4) { // the header is 12x32bit long
> +if(ldl_p(header+i) == 0x1BADB002) {

I wonder if there is any reason why you didn't just replace the 1024 by
8192 in load_linux but added an XXX. Would this cause any problems I
missed? With this change and replacing 256 by 8192 in the above code it
works for my kernel, too.

Anyway, I think the for condition should be i < 4 * (256 - 12), even
without changing the 1024.

Kevin

[Qemu-devel] qemu softmmu_template.h softmmu_header.h osdep....

[Fabrice Bellard]

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 CPUTLBEntry size a power of two

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/softmmu_template.h?cvsroot=qemu&r1=1.21&r2=1.22
http://cvs.savannah.gnu.org/viewcvs/qemu/softmmu_header.h?cvsroot=qemu&r1=1.19&r2=1.20
http://cvs.savannah.gnu.org/viewcvs/qemu/osdep.h?cvsroot=qemu&r1=1.13&r2=1.14
http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-defs.h?cvsroot=qemu&r1=1.28&r2=1.29

Re: [Qemu-devel] [patch] cocoa.m - Core Graphics support

[Alexander Graf]

On Jan 30, 2008, at 9:30 PM, Mike Kronenberg wrote:



On 30.01.2008, at 19:59, Alexander Graf wrote:



On Jan 21, 2008, at 5:18 PM, Mike Kronenberg wrote:


This is a complete rewrite of cocoa.m to support Core Graphics.

As mentioned in earlier threads, the QuickDraw API is depreciated  
starting with OS X 10.4.

Now with OS X 10.5 it won't even compile QuickDraw code on x86_64.


This implementation of cocoa.m has the following features:

[new] partial drawing of the window as needed, implemented with CG.
[new] fullscreen support
[new] tablet support
[new] View menu and item to enter Fullscreen (cmd-f)
[new] Help menu and items to show qemu-doc.html (cmd-?) and qemu- 
tec.html in the OS X "Help Viewer"

[new] -name is shown in Title-bar of window
[fix] Application menu creation for 10.4+ (API is private as of  
10.4)
[fix] Mouse-clicks on the guests window widgets are no longer  
intercepted
[fix] apple keyboard shortcuts forwarded (minimize (cmd-m), hide  
QEMU (cmd-h), quit QEMU (cmd-q))


It should compile on ppc/intel starting form 10.3 (10.2 with the  
known workarounds).


Please test and comment


I'm sorry that I didn't find the time to test this implementation  
before.


It's damn slow.

I ran it using my x86_64 on 10.5.1, targetting x86_64-softmmu and  
booting a linux kernel. I could literally see every like getting  
repainted (which btw did not happen with my quick hacky version I  
sent to the list some time ago).


I think the major problem is that too much is being done during  
drawRect. If I understand the code correctly, you create CGImage  
objects on every repaint, which is prone to be slow.


Why not simply reuse the framebuffer qemu provides anyway and leave  
everything else to CG?


Alex





Hi Alex,

yes, as stated earlyer, it is slower than Quickdraw, especially if  
the whole screen is redrawn. Overal emulation speed for GUI apps is  
faster, dough, as only small portions of the screen are redrawn.


That's good to hear. I tend to use Linux in command line mode in qemu  
quite often though, so for me the most important thing is full screen  
update, which apparently became slower. Merely running an SDL targeted  
qemu (did this on x86_64 linux) vs a cocoa one shows that something  
feels wrong on cocoa. Maybe there is no other way around this, but I  
still don't like seeing the screen scroll line for line ;-).


Unfortunately I don't have the time right now to investigate this in  
detail and I am really not into graphics programming usually. So for  
the time being it is still _way_ better than a solution that doesn't  
even compile.


The one thing I want to stress here is that maybe it might be worth  
looking into alternatives. If I find the time to do it, I will do so.  
I somehow like the idea of having a GL based video output.


Alex

[Qemu-devel] RE: [kvm-devel] [PATCH] Making SLIRP code more 64-bit clean

[Zhang, Xiantao]

Unfortunately, it can's apply on tip. Could you attach the diff ?
Thanks
Xiantao

[Qemu-devel] arm-test example file-system image

[b93049]

Hello,
I have some questions when I want to create a new file system of arm-test.
The arm-test could be download from http://fabrice.bellard.free.fr/qemu/arm-
test-0.2.tar.gz . 
It is a ramdisk . I could open it to see what it has.
Now I want to create a new ramdisk to run in the same style od arm-test.
I just use busybox_1_1_stable to produce my binary execution files.
I have bin, linuxrc, etc(but it is empty), sbin and usr.
I should add some files to etc, and I have see some files in the arm-test 
file system image etc/.
But now I don't know how many files should I have to boot it.
I have just copy the files in arm-test file system image and edit a file.
The files I changed are follows:
etc/inittab -> "::sysinit:/etc/init.d/rcS"

But when I run it, It tell me that it can't find etc/init.d/rcS !!
I have add it to my fiel system !
Could someone tell me what shouls I do 

Thanks .




--
Open WebMail Project (http://openwebmail.org)