headers
Paul Brook | 1 Feb 2008 01:14
Gravatar

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

> -    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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Permalink | Reply | 4 comments |
headers
Anthony Liguori | 1 Feb 2008 01:25
Picon
Favicon

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

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) {
(Continue reading)

Permalink | Reply | 4 comments |
headers
Anthony Liguori | 1 Feb 2008 01:28
Picon
Favicon

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

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
>   

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Permalink | Reply | 2 comments |
headers
Paul Brook | 1 Feb 2008 01:37
Gravatar

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

> >> +#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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Permalink | Reply | 2 comments |
headers
Paul Brook | 1 Feb 2008 01:40
Gravatar

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

> > 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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Permalink | Reply | 0 comments |
headers
Anthony Liguori | 1 Feb 2008 01:40
Picon
Favicon

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

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Scott Pakin | 1 Feb 2008 02:37

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

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.000000000 -0700
+++ kvm-60/qemu/exec-all.h	2008-01-31 17:36:34.000000000 -0700
 <at>  <at>  -169,7 +169,7  <at>  <at> 
  #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.000000000 -0700
+++ kvm-60/qemu/slirp/ip.h	2008-01-31 17:29:28.000000000 -0700
 <at>  <at>  -193,13 +193,8  <at>  <at> 
  #endif
  #endif
(Continue reading)

Permalink | Reply | 0 comments |
headers
Zhang, Xiantao | 1 Feb 2008 02:26
Picon
Favicon

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

Blue Swirl wrote:
> On 1/30/08, Scott Pakin <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.
>> 
>> 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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Zhang, Xiantao | 1 Feb 2008 03:44
Picon
Favicon

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

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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Permalink | Reply | 0 comments |
headers
Mulyadi Santosa | 1 Feb 2008 03:41
Picon

Re: More about slow clock in guest OS

hello Sergey...

On 1/31/08, Sergey Bychkov <sergb <at> unichrom.com> 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.

pffff... 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...
(Continue reading)

Permalink | Reply | 2 comments |

Gmane