date:20080428

Bugs item #1952988, was opened at 2008-04-27 18:25
Message generated for change (Comment added) made by mtosatti
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1952988&group_id=180599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: kernel
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Carlo Marcelo Arenas Belon (carenas)
Assigned to: Nobody/Anonymous (nobody)
Summary: in-kernel PIT blocks DragonFlyBSD from booting

Initial Comment:
starting with kvm 64, DragonFlyBSD guests won't be able to boot unless 
-no-kvm-pit or -no-kvm-irqchip is used (-no-kvm works as well) :

cpu model: Intel(R) Core(TM)2 CPU
  kvm version: kvm 66 (kvm>=64 fails, kvm<=63 works)
  host kernel: 2.6.24-gentoo-r4 (SMP)
host arch: x86_64

to replicate, download dragonfly ISO (it is a livecd) and boot from it :

  kvm -curses -cdrom dfly-1.12.2_REL.iso -boot d

--

Comment By: Marcelo Tosatti (mtosatti)
Date: 2008-04-28 17:30

Message:
Logged In: YES 
user_id=2022487
Originator: NO

DragonFlyBSD uses mode 4 of the PIT which the in-kernel emulation
simply ignores.

Mode 4 seems to be similar to one-shot mode, other than the fact
that mode 4 starts counting after the next CLK pulse once programmed,
and mode1 starts counting immediately, so this _should_ be OK:

http://people.redhat.com/~mtosatti/kvm-i8254-mode4.patch

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1952988&group_id=180599

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] [PATCH 1 of 3] Remove dynamic allocation of /hypervisor node from device tree in memory

1 file changed, 1 deletion(-)
qemu/hw/ppc440_bamboo.c |1 -


In 2.6.26 wait is now enabled by default. With this the /hypervisor node will 
not be need to be idetified to enable the guest to go into wait state while 
idle.

Signed-off-by: Jerone Young <[EMAIL PROTECTED]>

diff --git a/qemu/hw/ppc440_bamboo.c b/qemu/hw/ppc440_bamboo.c
--- a/qemu/hw/ppc440_bamboo.c
+++ b/qemu/hw/ppc440_bamboo.c
@@ -163,7 +163,6 @@ void bamboo_init(ram_addr_t ram_size, in
dt_cell(fdt, "/chosen", "linux,initrd-end",
(initrd_base + initrd_size));
dt_string(fdt, "/chosen", "bootargs", (char *)kernel_cmdline);
-   dt_node(fdt, "/", "hypervisor");
 #endif
 
if (kvm_enabled()) {

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] [PATCH 0 of 3] Fixes for PowerPC Qemu KVM

This set of patches contain fixes for bamboo board model, as well as provides 
more functionality for device tree manipulation.

Signed-off-by: Jerone Young <[EMAIL PROTECTED]>

3 files changed, 22 insertions(+), 1 deletion(-)
qemu/hw/device_tree.c   |   16 
qemu/hw/device_tree.h   |2 ++
qemu/hw/ppc440_bamboo.c |5 -

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] [PATCH 2 of 3] Add function dt_cell_multi to hw/device_tree.c

2 files changed, 18 insertions(+)
qemu/hw/device_tree.c |   16 
qemu/hw/device_tree.h |2 ++


This patch adds function dt_cell_multi to allow for manipulation of device tree 
properties that contain mulitiple 32bit values.

Signed-off-by: Jerone Young <[EMAIL PROTECTED]>

diff --git a/qemu/hw/device_tree.c b/qemu/hw/device_tree.c
--- a/qemu/hw/device_tree.c
+++ b/qemu/hw/device_tree.c
@@ -162,6 +162,22 @@ void dt_cell(void *fdt, char *node_path,
}
 }
 
+/* This function is to manipulate a cell with multiple values */
+void dt_cell_multi(void *fdt, char *node_path, char *property,
+   uint32_t *val_array, int size)
+{
+   
+   int offset;
+   int ret;
+   offset = get_offset_of_node(fdt, node_path);
+   ret = fdt_setprop(fdt, offset, property, val_array, size);
+   if (ret < 0) {
+   printf("Unable to set device tree property '%s'\n",
+   property);
+   exit(1);
+   }
+}
+
 void dt_string(void *fdt, char *node_path, char *property,
char *string)
 {
diff --git a/qemu/hw/device_tree.h b/qemu/hw/device_tree.h
--- a/qemu/hw/device_tree.h
+++ b/qemu/hw/device_tree.h
@@ -19,6 +19,8 @@ void dump_device_tree_to_file(void *fdt,
 void dump_device_tree_to_file(void *fdt, char *filename);
 void dt_cell(void *fdt, char *node_path, char *property,
uint32_t val);
+void dt_cell_multi(void *fdt, char *node_path, char *property,
+   uint32_t *val_array, int size);
 void dt_string(void *fdt, char *node_path, char *property,
char *string);
 void dt_node(void *fdt, char *node_parent_path, char *name);

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] [PATCH 3 of 3] Fix memory defined in device tree by declaring it dynamically for bamboo board model

1 file changed, 4 insertions(+)
qemu/hw/ppc440_bamboo.c |4 


This fixes a issue where the amount of memory is not properly being defined in 
the device tree. It currently is hardcoded for 144MB. The result is that if you 
specify a memory size below the hardcoded size, the guest crashes. This patch 
now dynamically changes the device tree to the memory value specified.

Signed-off-by: Jerone Young <[EMAIL PROTECTED]>

diff --git a/qemu/hw/ppc440_bamboo.c b/qemu/hw/ppc440_bamboo.c
--- a/qemu/hw/ppc440_bamboo.c
+++ b/qemu/hw/ppc440_bamboo.c
@@ -50,6 +50,7 @@ void bamboo_init(ram_addr_t ram_size, in
int i=0, k=0;
uint32_t cpu_freq;
uint32_t timebase_freq;
+   uint32_t mem_reg_property[]={0, 0, ram_size};
 
printf("%s: START\n", __func__);
 
@@ -73,6 +74,7 @@ void bamboo_init(ram_addr_t ram_size, in
printf("WARNING: %i MB left over memory is ram\n",
bytes_to_mb((int)tmp_ram_size));
ram_size -= tmp_ram_size;
+   mem_reg_property[2] = ram_size;
}
 
/* Setup CPU */
@@ -159,6 +161,8 @@ void bamboo_init(ram_addr_t ram_size, in
/* manipulate device tree in memory */
dt_cell(fdt, "/cpus/[EMAIL PROTECTED]", "clock-frequency", cpu_freq);
dt_cell(fdt, "/cpus/[EMAIL PROTECTED]", "timebase-frequency", 
timebase_freq);
+   dt_cell_multi(fdt, "/memory", "reg", mem_reg_property,
+   sizeof(mem_reg_property));
dt_cell(fdt, "/chosen", "linux,initrd-start", initrd_base);
dt_cell(fdt, "/chosen", "linux,initrd-end",
(initrd_base + initrd_size));

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] Feedback and errors

2008-04-28 Thread nadim khemir

Hi, great work.

While playing with kvm-qemu I noticed a few points that might be of interrest:

1/ -loadvm and -snapshot don't work together. It works as if -loadvm wasn't 
passed as argument

2/ two instances of kvm can be passed the same -hda. There is no locking 
whatsoever. This messes up things seriously.

3/ trying to run 'savevm' in the qemu console when -usb is used results in

(qemu) savevm scite
(qemu) exception 13 (0)
rax  rbx  rcx 0010 rdx 

...

This is documented but a warning in the console would be better than a crash

if the vm is stopped first, 'savevm' works but it still crashes on 'cont' 
instead

4/ if -vga-std is used when doing a 'savevm', 'loadvm' restores a black 
screen. Everything is there and with some gymnastic (moving a window around) 
the screen is like it should be.

5/ -usbdevice tablet is a must, 'ctl+alt' is just too painfull! is it possible 
to get the same effect (with another system) and still be able to 'savevm'?

6/ If you use -usbdevice tablet, keyboard is first handled by guest OS. In my 
case I have 'alt F4' close windows in the host OS. If I try to close a window 
in the guest OS with 'alt f4', it closes qemu altogether.

7/ On the other hand, mouse events are _not_ handled by the gues OS first, IE: 
alt click isn't handled by X but by windows (in this case)

8/ keyboard input lost when switching to full screen or back. fixed by 
using 'ctl+alt' twice

9/ IMHO, the way "versionning" with 'savevm' is done could feel more natural.

first run
time --> stop VM
 ^  |
 |  |
 |  v
   savevm state1automatically save "HEAD" in -hda



second run
time -->stop VM
 ^ |
 | |
 | v
   loadvm state1   automatically save "HEAD" in -hda
   ^
   |
.--'
|
   .-.
   | I believe most people want to save in 'state1'  |
   | or possibly in 'state2' but few want to |
   | override "HEAD" |
   '-'


automatically overriding 'state1' feels as wrong as overriding "HEAD". I 
believe that a -savevm to qemu would be a good idea. If nothing is passed as 
argument "HEAD" is used. That would preserve "HEAD" and allow saving to a 
user defined vm snapshot.

10/ subscription to the mailing list doesn't seem to work

Cheers, Nadim.

# what kvm version you are using. qemu 0.9.1

# the cpu, arch  and host kernel version: Linux 2.6.24 #9 SMP x86_64 Intel(R) 
Core(TM)2 Quad CPU @ 2.66GHz GenuineIntel GNU/Linux

# what guest you are using, including OS type Windows XP SP2 (32 I guess)

# the qemu command line you are using to start the guest
qemu-system-x86_64 -no-acpi -m 1536 -hda overlay.img -boot c -monitor 
stdio -usb -smp 2 -std-vga -smb /home/nadim/ -k
fr

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] WARN_ON in kvm_queue_exception_e triggers

On Mon, Apr 28, 2008 at 07:35:10PM +0200, Jan Kiszka wrote:
> Hi,
> 
> sorry, the test environment is not really reproducible (stock kvm-66,
> yet unpublished NMI support by Sheng Yang and me, special guest), but
> I'm just fishing for some ideas on what may cause the flood of the
> following warning in my kernel log:
> 
> [ cut here ]
> WARNING: at /data/kvm-66/kernel/x86.c:180
> kvm_queue_exception_e+0x30/0x54 [kvm]()
> Modules linked in: ipt_MASQUERADE kvm_intel kvm bridge tun ip6t_LOG
> nf_conntrack_ipv6 xt_pkttype ipt_LOG xt_limit snd_pcm_oss snd_mixer_oss
> snd_seq snd_seq_device nls_utf8 cifs af_packet ip6t_REJECT xt_tcpudp
> ipt_REJECT xt_state iptable_mangle iptable_nat nf_nat iptable_filter
> ip6table_mangle nf_conntrack_ipv4 nf_conntrack ip_tables ip6table_filter
> ip6_tables cpufreq_conservative x_tables cpufreq_userspace
> cpufreq_powersave acpi_cpufreq ipv6 microcode fuse ohci_hcd loop rfcomm
> l2cap wlan_scan_sta ath_rate_sample ath_pci snd_hda_intel wlan pcmcia
> firmware_class hci_usb snd_pcm snd_timer ath_hal(P) sdhci battery
> bluetooth button ohci1394 mmc_core rtc_cmos parport_pc intel_agp
> rtc_core dock ac snd_page_alloc iTCO_wdt ieee1394 sky2 rtc_lib
> yenta_socket parport snd_hwdep snd iTCO_vendor_support i2c_i801
> rsrc_nonstatic pcmcia_core sg i2c_core soundcore serio_raw joydev
> sha256_generic aes_x86_64 aes_generic cbc dm_crypt crypto_blkcipher
> usbhid hid ff_memless sd_mod ehci_hcd uhci_hcd usbcore dm_snapshot
> dm_mod edd ext3 mbcache jbd fan ata_piix ahci libata scsi_mod thermal
> processor
> Pid: 4718, comm: qemu-system-x86 Tainted: PN
> 2.6.25-rc5-git2-109.8-default #1
> 
> Call Trace:
>  [] dump_trace+0xc4/0x576
>  [] show_trace+0x40/0x57
>  [] _etext+0x72/0x7b
>  [] warn_on_slowpath+0x58/0x80
>  [] :kvm:kvm_queue_exception_e+0x30/0x54
>  [] :kvm:kvm_task_switch+0xca/0x20a
>  [] :kvm_intel:handle_task_switch+0x19/0x1b
>  [] :kvm_intel:kvm_handle_exit+0x7f/0x9c
>  [] :kvm:kvm_arch_vcpu_ioctl_run+0x49b/0x686
>  [] :kvm:kvm_vcpu_ioctl+0xf7/0x3ca
>  [] vfs_ioctl+0x2a/0x78
>  [] do_vfs_ioctl+0x247/0x261
>  [] sys_ioctl+0x55/0x77
>  [] system_call_after_swapgs+0x8a/0x8f
>  [<7faed2969267>]
> 
> ---[ end trace 5d286714f3c5c50f ]---

Hmm, seems we have to check for DF and triple faults in the
kvm_queue_exception functions too. Does the attached patch fix the
problem (patch is against kvm-66).

Joerg

-- 
   |   AMD Saxony Limited Liability Company & Co. KG
 Operating | Wilschdorfer Landstr. 101, 01109 Dresden, Germany
 System|  Register Court Dresden: HRA 4896
 Research  |  General Partner authorized to represent:
 Center| AMD Saxony LLC (Wilmington, Delaware, US)
   | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy
diff --git a/kernel/x86.c b/kernel/x86.c
index ef2aba9..a4da0e8 100644
--- a/kernel/x86.c
+++ b/kernel/x86.c
@@ -144,9 +144,23 @@ void kvm_set_apic_base(struct kvm_vcpu *vcpu, u64 data)
 }
 EXPORT_SYMBOL_GPL(kvm_set_apic_base);
 
+static void handle_multiple_faults(struct kvm_vcpu *vcpu)
+{
+   if (vcpu->arch.exception.nr != DF_VECTOR) {
+   printk(KERN_DEBUG "kvm: inject_page_fault:"
+   " double fault\n");
+   vcpu->arch.exception.nr = DF_VECTOR;
+   vcpu->arch.exception.error_code = 0;
+   } else
+   set_bit(KVM_REQ_TRIPLE_FAULT, &vcpu->requests);
+}
+
 void kvm_queue_exception(struct kvm_vcpu *vcpu, unsigned nr)
 {
-   WARN_ON(vcpu->arch.exception.pending);
+   if (vcpu->arch.exception.pending) {
+   handle_multiple_faults(vcpu);
+   return;
+   }
vcpu->arch.exception.pending = true;
vcpu->arch.exception.has_error_code = false;
vcpu->arch.exception.nr = nr;
@@ -157,25 +171,16 @@ void kvm_inject_page_fault(struct kvm_vcpu *vcpu, 
unsigned long addr,
   u32 error_code)
 {
++vcpu->stat.pf_guest;
-   if (vcpu->arch.exception.pending) {
-   if (vcpu->arch.exception.nr == PF_VECTOR) {
-   printk(KERN_DEBUG "kvm: inject_page_fault:"
-   " double fault 0x%lx\n", addr);
-   vcpu->arch.exception.nr = DF_VECTOR;
-   vcpu->arch.exception.error_code = 0;
-   } else if (vcpu->arch.exception.nr == DF_VECTOR) {
-   /* triple fault -> shutdown */
-   set_bit(KVM_REQ_TRIPLE_FAULT, &vcpu->requests);
-   }
-   return;
-   }
vcpu->arch.cr2 = addr;
kvm_queue_exception_e(vcpu, PF_VECTOR, error_code);
 }
 
 void kvm_queue_exception_e(struct kvm_vcpu *vcpu, unsigned nr, u32 error_code)
 {
-   WARN_ON(vcpu->arch.exception.pending);
+   if (vcpu->arch.exception.pending) {
+   handle_multiple_faults(vcpu);
+   return;
+   }
vcpu->arch.exc

Re: [kvm-devel] [PATCH 01 of 12] Core of mmu notifiers

2008-04-28 Thread Christoph Lameter

On Sun, 27 Apr 2008, Andrea Arcangeli wrote:

> Talking about post 2.6.26: the refcount with rcu in the anon-vma
> conversion seems unnecessary and may explain part of the AIM slowdown
> too. The rest looks ok and probably we should switch the code to a
> compile-time decision between rwlock and rwsem (so obsoleting the
> current spinlock).

You are going to take a semphore in an rcu section? Guess you did not 
activate all debugging options while testing? I was not aware that you can 
take a sleeping lock from a non preemptible context.

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] [ kvm-Bugs-1895893 ] KVM-60+ halts, when using SCSI

Bugs item #1895893, was opened at 2008-02-18 01:44
Message generated for change (Comment added) made by alfmel
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1895893&group_id=180599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Technologov (technologov)
Assigned to: Nobody/Anonymous (nobody)
Summary: KVM-60+ halts, when using SCSI

Initial Comment:
Host: Intel CPU, F7/x64, KVM-60+ from git (userspace: kvm-60-155-g4422f97, 
kernelspace: kvm-60-10207-g9ef1f35)

When installing Windows XP guest on emulated SCSI disk, KVM lock ups.

The Command sent to Qemu/KVM: 

/usr/local/bin/qemu-system-x86_64 -drive 
file=/vm/WindowsXP.qcow2,if=scsi,boot=on -m 128 -monitor 
tcp:localhost:4503,server,nowait -cdrom 
/isos/windows/WindowsXP-SP2-Home-Pro-Tablet.iso -boot d -name WindowsXP

Reproducible: Sometimes.

Symptons:
-The image during XP setup looks halted/locked, and no progress over 12 hours.
-kvm_stat shows zero KVM activity.
-Host CPU is 100% busy.
-Qemu doesn't responds to any commands (such as alt+f2).

GNU Debugger shows:
(gdb) bt
#0  lsi_execute_script (s=0x2bed030) at ../cpu-all.h:848
#1  0x0048a2e9 in qcow_aio_write_cb (opaque=0x2c8a050, ret=0)
at block-qcow2.c:947
#2  0x0041898f in qemu_aio_poll ()
at /root/git/kvm/qemu/block-raw-posix.c:318
#3  0x0040de3c in main_loop_wait (timeout=0)
at /root/git/kvm/qemu/vl.c:7822
#4  0x004fd81d in kvm_eat_signals (env=0x2b52400, timeout=0)
at /root/git/kvm/qemu/qemu-kvm.c:204
#5  0x004fd859 in kvm_main_loop_wait (env=0x2b52400, timeout=0)
at /root/git/kvm/qemu/qemu-kvm.c:211
#6  0x004fe0a6 in kvm_main_loop_cpu (env=0x2b52400)
at /root/git/kvm/qemu/qemu-kvm.c:309
#7  0x00410e3d in main (argc=,
argv=0x7fff06235728) at /root/git/kvm/qemu/vl.c:7856

Dmesg shows:

apic write: bad size=1 fee00030
Ignoring de-assert INIT to vcpu 0
Ignoring de-assert INIT to vcpu 0
apic write: bad size=1 fee00030
Ignoring de-assert INIT to vcpu 0
Ignoring de-assert INIT to vcpu 0

...looping forever.

-Alexey "Technologov", 18.02.2008.

--

Comment By: Alf Mel (alfmel)
Date: 2008-04-28 14:11

Message:
Logged In: YES 
user_id=1865908
Originator: NO

OK.  I've applied the matley patch and your debug patch to KVM 66.  I've
also been able to reproduce the problem on a raw SCSI disk while installing
Windows 2003.  You can find the log at:

http://mel.byu.edu/kvm-scsi-debug.log.bz2

--

Comment By: Marcelo Tosatti (mtosatti)
Date: 2008-04-26 17:45

Message:
Logged In: YES 
user_id=2022487
Originator: NO

Alexey, Alberto,

I'm unable to reproduce the problem with the Linux driver.

The Windows SCSI SCRIPTS is different so that might the reason. The 
state machine is relatively complex depending on this SCRIPTS code.

Please try the following:

1 - Attempt to reproduce the problem with raw disk instead of qcow2.
2 - Apply matley's patch below, and on top of that, this debug patch:
http://people.redhat.com/~mtosatti/lsi-debug-crash.patch

And then run qemu-kvm as usual, but redirect stderr output to a file:

# qemu-kvm options 2> log-scsi-crash.txt

Once the crash happens, there should be a pattern that repeats in this
output. 
With that information its easier to understand what is going on.

Thanks.


--

Comment By: Alf Mel (alfmel)
Date: 2008-04-11 16:46

Message:
Logged In: YES 
user_id=1865908
Originator: NO

I've confirmed the problem with KVM-65 as well.  I applied the patch but
it didn't work; I still experienced lockups.  I am trying to install
Windows Server 2003 on a SCSI disk and the installation keeps locking up on
different parts of the file copy process.  I'm using qcow2 disk format.  I
tried using raw format and it would lock up consistently when formatting
the disk.  I have tried installing W2K3 at least a dozen times with the
same lockups.  As part of my configuration, I move the monitor to run on a
telnet server.  When the lockup occurs, I can't connect to the monitor via
telnet.

I am also experiencing boot problems with Grub on SCSI disks.  I reported
the problem on the mailing list:

http://article.gmane.org/gmane.comp.emulators.kvm.devel/15884

I don't know if the problems are related.

--

Comment By: lanconnected (lanconnected)
Date: 2008-04-08 10:17

Message:
Logged In: YES 
user_id=2041746
Originator: NO

Applied proposed patch on kvm-65. Windows XP Pro can be installed on scsi
disk and boots up, but hangs unpredictably dur

Re: [kvm-devel] kvm-67: kernel panic while booting debian-40r3-i386-businesscard.iso

On Mon, Apr 28, 2008 at 06:50:22PM +0200, Jan Luebbe wrote:
> Hi!
> 
> I'm preparing kvm-67 for debian. While testing i noticed a problem:
> 
> When booting the debian installer from the official CD [1] this problem:
> 
> CPU: L1 I cache: 32K, L1 D cache: 32K
> CPU: L2 cache: 2048K
> Compat vDSO mapped to e000.
> CPU: Intel QEMU Virtual CPU version 0.9.1 stepping 03
> Checking 'hlt' instruction... OK.
> ACPI: Core revision 20060707
> invalid opcode:  [#1]
> Modules linked in:
> CPU:0   
> EIP:0060:[]Not tainted VLI
> EFLAGS: 00010202   (2.6.18-6-486 #1)
> EIP is at kmem_cache_zalloc+0x2a/0x53
> eax: 000a   ebx: c7fe75c0   ecx: c7fe9e00   edx: 00d0
> esi: c02c50c0   edi: 0202   ebp: c036bd20   esp: c030ff80
> ds: 007b   es: 007b   ss: 0068
> Process swapper (pid: 0, ti=c030e000 task=c02bd7a0 task.ti=c030e000)
> Stack: 0004 c028f968 c029c49a c0146d5b 0004  0014
> c029c499
>0046 c030ffc4 0046 0046   00039100
> c0302800
>003a7007 c01c7e90    c01db3b5 c0378ce8
> c01dcf07
> Call Trace: 
>  [] kmem_cache_create+0x15e/0x410
>  [] acpi_os_create_cache+0x10/0x1c
>  [] acpi_ut_create_caches+0x19/0x93
>  [] acpi_ut_init_globals+0x5/0x1de
>  [] acpi_initialize_subsystem+0x1b/0x56
>  [] acpi_early_init+0x45/0xfe
>  [] start_kernel+0x26b/0x272
> Code: c3 57 56 53 89 c6 9c 5f fa 8b 08 83 39 00 74 12 c7 41 0c 01 00 00
> 00 8b 01
>  48 89 01 8b 5c 81 10 eb 07 e8 a5 fb ff ff 89 c3 57 9d <0f> 0d 0b 90 85
> db 74 1b
>  8b 56 10 31 c0 89 d1 c1 e9 02 89 df f3
> EIP: [] kmem_cache_zalloc+0x2a/0x53 SS:ESP 0068:c030ff80
>  <0>Kernel panic - not syncing: Attempted to kill the idle task!

I tried to reproduce this on an AMD system with no success. But when
looking into the code of kmem_cache_zalloc this looks like a guest state
corruption. The guest disables interrupts and the hypervisor reenables
them which triggers the BUG() macro. Maybe kvmtrace can give a hint
which intercept causes this.

Joerg


-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH] Fix QEMU vcpu thread race with apic_reset

2008-04-28 Thread Anthony Liguori

Ryan Harper wrote:
> * Avi Kivity <[EMAIL PROTECTED]> [2008-04-26 02:23]:
>   
>> Please reuse qemu_mutex for this, no need for a new one.
>> 
>
> I'm having a little trouble wrapping my head around all of the locking
> here.  If I avoid qemu_mutex and use a new one, I've got everything
> working.  However, attemping to use qemu_mutex is stepping into a pile
> of locking crap.  I'm sure there is a good reason... 
>
> The current code looks like this:
>
> Thread1:
> main()
>   kvm_qemu_init() // mutex_lock()
>   machine->init()
>pc_init1()
> pc_new_cpu()
>  cpu_init()
>   cpu_x86_init()
>kvm_init_new_ap() // create vcpu Thread2
><--  
>   <--  
>  <--  
> <--  
><--  
>   <--  
>   kvm_main_loop() // mutex_unlock()
> 
> Thread2:
> ap_main_loop()
>  /* vcpu init */
>  kvm_main_loop_cpu()
>   kvm_main_loop_wait() // mutex_unlock() on enter, lock on exit
>kvm_eat_signals()   // mutex_lock() on enter, unlock on exit
><--
>   <--
>  <--
>   

The qemu_mutex is meant to ensure that the QEMU code is only ever 
entered by one thread at a time.  QEMU is not thread-safe so this is 
necessary.  It's a little odd because we're taking this lock initially 
by being called from QEMU code.  Here's the basic theory of locking AFAICT:

kvm_main_loop_cpu() is the main loop for each VCPU.  It must acquire the 
QEMU mutex since it will call into normal QEMU code to process events.  
Whenever a VCPU is allowed to run, or when the VCPU is idling, it needs 
to release the QEMU mutex.  The former is done via the post_kvm_run() 
and pre_kvm_run() hooks.  The later is done within kvm_main_loop_wait().

kvm_main_loop_wait() will release the QEMU mutex and call 
kvm_eat_signals() which calls kvm_eat_signal() which will issue a 
sigtimedwait().  This is where we actually idle (and why SIGIO is so 
important right now).  We don't want to idle with the QEMU mutex held as 
that may result in dead lock so this is why we release it here.

kvm_eat_signal() has to acquire the lock again in order to dispatch IO 
events (via kvm_process_signal()).

Regards,

Anthony Liguori

> It wedges up in kvm_init_new_ap() if I attempt acquire qemu_mutex.
> Quite obvious after I looked at the call trace and discovered
> kvm_qemu_init() locking on exit.  I see other various functions that
> unlock and then lock; I really don't want to wade into this mess...
> rather whomever cooked it up should do some cleanup.  I tried the
> unlock, then re-lock on exit in kvm_init_new_ap() but that also wedged.
>
> Here is a rework with a new flag in vcpu_info indicating vcpu
> creation.  Tested this with 64 1VCPU guests booting with 1 second delay,
> and single 16-way SMP guest boot.
>
>   

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH 0/4] paravirt clock patches

2008-04-28 Thread Marcelo Tosatti

On Thu, Apr 24, 2008 at 10:37:04AM +0200, Gerd Hoffmann wrote:
>   Hi folks,
> 
> My first attempt to send out a patch series with git ...
> 
> The patches fix the kvm paravirt clocksource code to be compatible with
> xen and they also factor out some code which can be shared into a
> separate source files used by both kvm and xen.

The issue with SMP guests is still present. Booting with "nohz=off" resolves it.

Same symptoms as before, apic_timer_fn for one of the vcpu's is ticking way 
slower
than the remaining ones:

[EMAIL PROTECTED] ~]# cat /proc/timer_stats  | grep apic
  391,  4125 qemu-system-x86  apic_mmio_write (apic_timer_fn)
 2103,  4126 qemu-system-x86  apic_mmio_write (apic_timer_fn)
 1896,  4127 qemu-system-x86  apic_mmio_write (apic_timer_fn)
 1857,  4128 qemu-system-x86  apic_mmio_write (apic_timer_fn)

Let me know what else is needed, or any patches to try.

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] [PATCH] Update kernel/Makefile and remove x86 only entries

1 file changed, 25 insertions(+), 13 deletions(-)
kernel/Makefile |   38 +-


This patch removes static x86 entries and makes things work for multiple archs.

Signed-off-by: Jerone Young <[EMAIL PROTECTED]>

diff --git a/kernel/Makefile b/kernel/Makefile
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -1,5 +1,10 @@ include ../config.mak
 include ../config.mak
 
+ARCH_DIR=$(ARCH)
+ifneq '$(filter $(ARCH_DIR), x86_64 i386)' ''
+   ARCH_DIR=x86
+endif
+ 
 KVERREL = $(patsubst /lib/modules/%/build,%,$(KERNELDIR))
 
 DESTDIR=
@@ -18,10 +23,19 @@ _hack = mv $1 $1.orig && \
| sed '/\#include/! s/\blapic\b/l_apic/g' > $1 && rm $1.orig
 
 unifdef = mv $1 $1.orig && \
- unifdef -DCONFIG_X86 $1.orig > $1; \
+ unifdef -DCONFIG_$(shell echo $(ARCH_DIR)|tr '[:lower:]' '[:upper:]') 
$1.orig > $1; \
   [ $$? -le 1 ] && rm $1.orig
 
 hack = $(call _hack,$T/$(strip $1))
+
+ifneq '$(filter $(ARCH_DIR), x86)' ''
+HACK_FILES = kvm_main.c \
+   mmu.c \
+   vmx.c \
+   svm.c \
+   x86.c \
+   irq.h 
+endif
 
 all::
 #  include header priority 1) $LINUX 2) $KERNELDIR 3) include-compat
@@ -49,21 +63,19 @@ header-sync:
rm -rf $T
 
rm -f include/asm
-   ln -sf asm-x86 include/asm
-   ln -sf asm-x86 include-compat/asm
+   ln -sf asm-$(ARCH_DIR) include/asm
+   ln -sf asm-$(ARCH_DIR) include-compat/asm
 
 source-sync:
rm -rf $T
rsync --exclude='*.mod.c' -R \
- "$(LINUX)"/arch/x86/kvm/./*.[ch] \
- "$(LINUX)"/virt/kvm/./*.[ch] \
- $T/
-   $(call hack, kvm_main.c)
-   $(call hack, mmu.c)
-   $(call hack, vmx.c)
-   $(call hack, svm.c)
-   $(call hack, x86.c)
-   $(call hack, irq.h)
+"$(LINUX)"/arch/$(ARCH_DIR)/kvm/./*.[ch] \
+"$(LINUX)"/virt/kvm/./*.[ch] \
+$T/
+
+   for i in $(HACK_FILES); \
+   do $(call hack, $$i); done
+
for i in $$(find $T -type f -printf '%P '); \
do cmp -s $$i $T/$$i || cp $T/$$i $$i; done
rm -rf $T
@@ -72,7 +84,7 @@ install:
mkdir -p $(DESTDIR)/$(INSTALLDIR)
cp *.ko $(DESTDIR)/$(INSTALLDIR)
for i in $(ORIGMODDIR)/drivers/kvm/*.ko \
-$(ORIGMODDIR)/arch/x86/kvm/*.ko; do \
+$(ORIGMODDIR)/arch/$(ARCH_DIR)/kvm/*.ko; do \
if [ -f "$$i" ]; then mv "$$i" "$$i.orig"; fi; \
done
/sbin/depmod -a

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] performance with guests running 2.4 kernels (specifically RHEL3)

2008-04-28 Thread Marcelo Tosatti

On Fri, Apr 25, 2008 at 11:33:18AM -0600, David S. Ahern wrote:
> Most of the cycles (~80% of that 54k+) are spent in paging64_prefetch_page():
> 
> for (i = 0; i < PT64_ENT_PER_PAGE; ++i) {
> gpa_t pte_gpa = gfn_to_gpa(sp->gfn);
> pte_gpa += (i+offset) * sizeof(pt_element_t);
> 
> r = kvm_read_guest_atomic(vcpu->kvm, pte_gpa, &pt,
>   sizeof(pt_element_t));
> if (r || is_present_pte(pt))
> sp->spt[i] = shadow_trap_nonpresent_pte;
> else
> sp->spt[i] = shadow_notrap_nonpresent_pte;
> }
> 
> This loop is run 512 times and takes a total of ~45k cycles, or ~88 cycles per
> loop.
> 
> This function gets run >20,000/sec during some of the kscand loops.

Hi David,

Do you see the mmu_recycled counter increase?

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] fork() within a VM with MMU notifiers

2008-04-28 Thread Andrea Arcangeli

On Mon, Apr 28, 2008 at 11:11:56AM -0500, Anthony Liguori wrote:
> Here's my thinking as to why we don't want to destroy the VM in the mmu 
> notifiers ->release method.  I don't have a valid use-case for this but my 
> argument depends on the fact that this is something that should work.  
> Daemonizing a running VM may be a reasonable use-case.  It's useful to wait 
> to daemonize until you are sure that everything is working correctly so 
> it's not all that unreasonable to move the daemonize until after the VCPUs 
> have been launched.
>
> If you take a running VM, and pause all of the VCPUs, and then issue a 
> fork() followed by an immediate exit() in the parent process, the child 
> process should be able to unpause all the VCPUs and the guest should 
> continue running uninterrupted.

Fork shares nothing, the only thing that don't need to be duplicated
and copied are the ones that can be marked wrprotect in the
pagetables.

> From KVM's perspective, issuing the fork() will increment the reference 
> count of the file descriptor for the VM but otherwise, no real change 
> should happen.  The issue would now be that we must completely flush the 
> shadow page table cache.  In theory, MMU notifiers should do this for us.

Let's ignore sptes for now. What you miss for something like this to
remotely work is to copy all memslots so an ioctl issued on the parent
won't break the child too.

If you want to ever support the above you have to change fork() so
that fork() will also mmu_notifier_register in the child, copy
memslots, patch all kvm->mm, and do all other things needed for this
to work. Then yes, it'll work, but not because exit_mmap didn't
shutdown the VM of the parent, but because you won't notice anymore
that the vm in the parent was _entirely_ shutdown by ->release.

> When the parent process exits, this will result in exit_mmap() and will 
> destroy the KVM guest.  This leaves the child process with a file 
> descriptor that refers to a VM that is no longer valid.

Rightfully so, as nothing could possibly work anymore in that VM. If
it works in the child it'd be only because you copied all memslots in
the child and did many other things and you changed the fd to work on
a different kvm structure for parent and child.

You have to copy the memslots or then parent couldn't run at the same
time of the child.

> Just avoiding destroying the VM in the ->release() method won't fix this 
> use-case I don't think.  In general, I think we need to think a little more 
> about how fork() is handled with respect to mmu notifiers.

This has very little to do with mmu notifiers. Let's make this work
first:

if (fork()) {
   ioctl(delete a memslot)
} else {
   ioctl(create a memslot)
}

those two ops won't invoke mmu notifiers at all, and there's no chance
the above will work right now.

In short you think fork() exit() should allow the child to keep
working with the guest of the parent when infact they both need to
work on different guests, and if they do you won't notice ->release of
the parent shutting down the parent vm (just in case it runs exit()).

Thanks!

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] libkvm: initialize no_pit_creation

2008-04-28 Thread Jan Kiszka

Avi Kivity wrote:
> Marcelo Tosatti wrote:
>> Valgrind caught this:
>>
>> ==11754== Conditional jump or move depends on uninitialised value(s)
>> ==11754==at 0x50C9BC: kvm_create_pit (libkvm-x86.c:153)
>> ==11754==by 0x50CA7F: kvm_arch_create (libkvm-x86.c:178)
>> ==11754==by 0x50AB31: kvm_create (libkvm.c:383)
>> ==11754==by 0x4EE691: kvm_qemu_create_context (qemu-kvm.c:616)
>> ==11754==by 0x412031: main (vl.c:9653)
>>
>>   
> 
> Applied, thanks.  Isn't valgrind great?
> 

Yeah, it is. Reminds me of another warning I recently came across
(offsets may vary due to other patches:

==5801== 1 errors in context 1 of 2:
==5801== Conditional jump or move depends on uninitialised value(s)
==5801==at 0x53F4AE: kvm_register_userspace_phys_mem (libkvm.c:552)
==5801==by 0x521ACA: kvm_cpu_register_physical_memory (qemu-kvm.c:654)
==5801==by 0x45FC82: pc_init1 (pc.c:809)
==5801==by 0x461313: pc_init_pci (pc.c:1149)
==5801==by 0x43081B: main (vl.c:9845)

This silences valgrind and may even be correct (if I got the code path
right):

Signed-off-by: Jan Kiszka <[EMAIL PROTECTED]>

--- a/libkvm/libkvm.c
+++ b/libkvm/libkvm.c
@@ -328,9 +328,10 @@ static int kvm_create_default_phys_mem(k

 #ifdef KVM_CAP_USER_MEMORY
r = ioctl(kvm->fd, KVM_CHECK_EXTENSION, KVM_CAP_USER_MEMORY);
-   if (r > 0)
+   if (r > 0) {
+   kvm->physical_memory = NULL;
return 0;
-   else
+   } else
 #endif
r = kvm_alloc_kernel_memory(kvm, memory, vm_mem);
if (r < 0)

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] WARN_ON in kvm_queue_exception_e triggers

2008-04-28 Thread Jan Kiszka

Hi,

sorry, the test environment is not really reproducible (stock kvm-66,
yet unpublished NMI support by Sheng Yang and me, special guest), but
I'm just fishing for some ideas on what may cause the flood of the
following warning in my kernel log:

[ cut here ]
WARNING: at /data/kvm-66/kernel/x86.c:180
kvm_queue_exception_e+0x30/0x54 [kvm]()
Modules linked in: ipt_MASQUERADE kvm_intel kvm bridge tun ip6t_LOG
nf_conntrack_ipv6 xt_pkttype ipt_LOG xt_limit snd_pcm_oss snd_mixer_oss
snd_seq snd_seq_device nls_utf8 cifs af_packet ip6t_REJECT xt_tcpudp
ipt_REJECT xt_state iptable_mangle iptable_nat nf_nat iptable_filter
ip6table_mangle nf_conntrack_ipv4 nf_conntrack ip_tables ip6table_filter
ip6_tables cpufreq_conservative x_tables cpufreq_userspace
cpufreq_powersave acpi_cpufreq ipv6 microcode fuse ohci_hcd loop rfcomm
l2cap wlan_scan_sta ath_rate_sample ath_pci snd_hda_intel wlan pcmcia
firmware_class hci_usb snd_pcm snd_timer ath_hal(P) sdhci battery
bluetooth button ohci1394 mmc_core rtc_cmos parport_pc intel_agp
rtc_core dock ac snd_page_alloc iTCO_wdt ieee1394 sky2 rtc_lib
yenta_socket parport snd_hwdep snd iTCO_vendor_support i2c_i801
rsrc_nonstatic pcmcia_core sg i2c_core soundcore serio_raw joydev
sha256_generic aes_x86_64 aes_generic cbc dm_crypt crypto_blkcipher
usbhid hid ff_memless sd_mod ehci_hcd uhci_hcd usbcore dm_snapshot
dm_mod edd ext3 mbcache jbd fan ata_piix ahci libata scsi_mod thermal
processor
Pid: 4718, comm: qemu-system-x86 Tainted: PN
2.6.25-rc5-git2-109.8-default #1

Call Trace:
 [] dump_trace+0xc4/0x576
 [] show_trace+0x40/0x57
 [] _etext+0x72/0x7b
 [] warn_on_slowpath+0x58/0x80
 [] :kvm:kvm_queue_exception_e+0x30/0x54
 [] :kvm:kvm_task_switch+0xca/0x20a
 [] :kvm_intel:handle_task_switch+0x19/0x1b
 [] :kvm_intel:kvm_handle_exit+0x7f/0x9c
 [] :kvm:kvm_arch_vcpu_ioctl_run+0x49b/0x686
 [] :kvm:kvm_vcpu_ioctl+0xf7/0x3ca
 [] vfs_ioctl+0x2a/0x78
 [] do_vfs_ioctl+0x247/0x261
 [] sys_ioctl+0x55/0x77
 [] system_call_after_swapgs+0x8a/0x8f
 [<7faed2969267>]

---[ end trace 5d286714f3c5c50f ]---

I'm suspecting that it is the way our guest raises a triple fault in
order to initiate a restart. At least it tells us via virtual console
that it wants to restart, and those messages start around the same time.
So, while waiting for my colleagues to dig out the precise triple-fault
code pattern (for a cleaner test case), maybe someone could comment on
potential reasons for this warning - or even ways to resolve them.

Thanks!
Jan

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

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH] Fix QEMU vcpu thread race with apic_reset

2008-04-28 Thread Ryan Harper

* Avi Kivity <[EMAIL PROTECTED]> [2008-04-26 02:23]:
> 
> Please reuse qemu_mutex for this, no need for a new one.

I'm having a little trouble wrapping my head around all of the locking
here.  If I avoid qemu_mutex and use a new one, I've got everything
working.  However, attemping to use qemu_mutex is stepping into a pile
of locking crap.  I'm sure there is a good reason... 

The current code looks like this:

Thread1:
main()
  kvm_qemu_init() // mutex_lock()
  machine->init()
   pc_init1()
pc_new_cpu()
 cpu_init()
  cpu_x86_init()
   kvm_init_new_ap() // create vcpu Thread2
   <--  
  <--  
 <--  
<--  
   <--  
  <--  
  kvm_main_loop() // mutex_unlock()

Thread2:
ap_main_loop()
 /* vcpu init */
 kvm_main_loop_cpu()
  kvm_main_loop_wait() // mutex_unlock() on enter, lock on exit
   kvm_eat_signals()   // mutex_lock() on enter, unlock on exit
   <--
  <--
 <--


It wedges up in kvm_init_new_ap() if I attempt acquire qemu_mutex.
Quite obvious after I looked at the call trace and discovered
kvm_qemu_init() locking on exit.  I see other various functions that
unlock and then lock; I really don't want to wade into this mess...
rather whomever cooked it up should do some cleanup.  I tried the
unlock, then re-lock on exit in kvm_init_new_ap() but that also wedged.

Here is a rework with a new flag in vcpu_info indicating vcpu
creation.  Tested this with 64 1VCPU guests booting with 1 second delay,
and single 16-way SMP guest boot.

-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253   T/L: 678-9253
[EMAIL PROTECTED]


diffstat output:
 qemu-kvm.c |   14 --
 1 files changed, 12 insertions(+), 2 deletions(-)

Signed-off-by: Ryan Harper <[EMAIL PROTECTED]>
---
diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c
index 78127de..2768ea5 100644
--- a/qemu/qemu-kvm.c
+++ b/qemu/qemu-kvm.c
@@ -31,7 +31,9 @@ extern int smp_cpus;
 static int qemu_kvm_reset_requested;
 
 pthread_mutex_t qemu_mutex = PTHREAD_MUTEX_INITIALIZER;
+pthread_mutex_t vcpu_mutex = PTHREAD_MUTEX_INITIALIZER;
 pthread_cond_t qemu_aio_cond = PTHREAD_COND_INITIALIZER;
+pthread_cond_t qemu_vcpuup_cond = PTHREAD_COND_INITIALIZER;
 __thread struct vcpu_info *vcpu;
 
 struct qemu_kvm_signal_table {
@@ -53,6 +55,7 @@ struct vcpu_info {
 int stop;
 int stopped;
 int reload_regs;
+int created;
 } vcpu_info[256];
 
 pthread_t io_thread;
@@ -369,6 +372,10 @@ static void *ap_main_loop(void *_env)
 sigfillset(&signals);
 sigprocmask(SIG_BLOCK, &signals, NULL);
 kvm_create_vcpu(kvm_context, env->cpu_index);
+pthread_mutex_lock(&vcpu_mutex);
+vcpu->created = 1;
+pthread_cond_signal(&qemu_vcpuup_cond);
+pthread_mutex_unlock(&vcpu_mutex);
 kvm_qemu_init_env(env);
 kvm_main_loop_cpu(env);
 return NULL;
@@ -388,9 +395,12 @@ static void kvm_add_signal(struct qemu_kvm_signal_table 
*sigtab, int signum)
 
 void kvm_init_new_ap(int cpu, CPUState *env)
 {
+pthread_mutex_lock(&vcpu_mutex);
 pthread_create(&vcpu_info[cpu].thread, NULL, ap_main_loop, env);
-/* FIXME: wait for thread to spin up */
-usleep(200);
+while (vcpu_info[cpu].created == 0) {
+pthread_cond_wait(&qemu_vcpuup_cond, &vcpu_mutex);
+}
+pthread_mutex_unlock(&vcpu_mutex);
 }
 
 static void qemu_kvm_init_signal_tables(void)

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] fork() within a VM with MMU notifiers

2008-04-28 Thread Anthony Liguori

Here's my thinking as to why we don't want to destroy the VM in the mmu 
notifiers ->release method.  I don't have a valid use-case for this but 
my argument depends on the fact that this is something that should 
work.  Daemonizing a running VM may be a reasonable use-case.  It's 
useful to wait to daemonize until you are sure that everything is 
working correctly so it's not all that unreasonable to move the 
daemonize until after the VCPUs have been launched.

If you take a running VM, and pause all of the VCPUs, and then issue a 
fork() followed by an immediate exit() in the parent process, the child 
process should be able to unpause all the VCPUs and the guest should 
continue running uninterrupted.

 From KVM's perspective, issuing the fork() will increment the reference 
count of the file descriptor for the VM but otherwise, no real change 
should happen.  The issue would now be that we must completely flush the 
shadow page table cache.  In theory, MMU notifiers should do this for us.

When the parent process exits, this will result in exit_mmap() and will 
destroy the KVM guest.  This leaves the child process with a file 
descriptor that refers to a VM that is no longer valid.

Just avoiding destroying the VM in the ->release() method won't fix this 
use-case I don't think.  In general, I think we need to think a little 
more about how fork() is handled with respect to mmu notifiers.

Regards,

Anthony Liguori

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH] [KVM POWERPC] Handle guest idle by emulating MSR[WE] writes

Hollis Blanchard wrote:
> This reduces host CPU usage when the guest is idle. However, the guest must
> set MSR[WE] in its idle loop, which Linux did not do until 2.6.26.
>
>   

Applied, thanks.

-- 
error compiling committee.c: too many arguments to function

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] kvm-67: kernel panic while booting debian-40r3-i386-businesscard.iso

2008-04-28 Thread Jan Luebbe

Hi!

I'm preparing kvm-67 for debian. While testing i noticed a problem:

When booting the debian installer from the official CD [1] this problem:

CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 2048K
Compat vDSO mapped to e000.
CPU: Intel QEMU Virtual CPU version 0.9.1 stepping 03
Checking 'hlt' instruction... OK.
ACPI: Core revision 20060707
invalid opcode:  [#1]
Modules linked in:
CPU:0   
EIP:0060:[]Not tainted VLI
EFLAGS: 00010202   (2.6.18-6-486 #1)
EIP is at kmem_cache_zalloc+0x2a/0x53
eax: 000a   ebx: c7fe75c0   ecx: c7fe9e00   edx: 00d0
esi: c02c50c0   edi: 0202   ebp: c036bd20   esp: c030ff80
ds: 007b   es: 007b   ss: 0068
Process swapper (pid: 0, ti=c030e000 task=c02bd7a0 task.ti=c030e000)
Stack: 0004 c028f968 c029c49a c0146d5b 0004  0014
c029c499
   0046 c030ffc4 0046 0046   00039100
c0302800
   003a7007 c01c7e90    c01db3b5 c0378ce8
c01dcf07
Call Trace: 
 [] kmem_cache_create+0x15e/0x410
 [] acpi_os_create_cache+0x10/0x1c
 [] acpi_ut_create_caches+0x19/0x93
 [] acpi_ut_init_globals+0x5/0x1de
 [] acpi_initialize_subsystem+0x1b/0x56
 [] acpi_early_init+0x45/0xfe
 [] start_kernel+0x26b/0x272
Code: c3 57 56 53 89 c6 9c 5f fa 8b 08 83 39 00 74 12 c7 41 0c 01 00 00
00 8b 01
 48 89 01 8b 5c 81 10 eb 07 e8 a5 fb ff ff 89 c3 57 9d <0f> 0d 0b 90 85
db 74 1b
 8b 56 10 31 c0 89 d1 c1 e9 02 89 df f3
EIP: [] kmem_cache_zalloc+0x2a/0x53 SS:ESP 0068:c030ff80
 <0>Kernel panic - not syncing: Attempted to kill the idle task!

Similar errors in acpi-functions also happen with all other linux
kernels i have here (2.6.22-25). -no-acpi makes no difference.

Userspace 66 works (with -66 and -67 kernel module), userspace 67 has
this problem (with -66 and -67 kernel module).

Host is an ThinkPad X60 (Core Duo), kernel 2.6.25.

I've tried to bisect the userspace, but the bug seems to be introduced
with the merge from qemu-cvs. Any tips on how to bisect the individual
commits on the qemu-cvs branch?

Thanks,
Jan Lübbe

[1]: 
http://cdimage.debian.org/debian-cd/4.0_r3/i386/iso-cd/debian-40r3-i386-businesscard.iso


-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] [PATCH]: Fake MSR_K7 performance counters

2008-04-28 Thread Chris Lalancette

Attached is a patch that fixes a guest crash when booting older Linux kernels.
The problem stems from the fact that we are currently emulating
MSR_K7_EVNTSEL[0-3], but not emulating MSR_K7_PERFCTR[0-3].  Because of this,
setup_k7_watchdog() in the Linux kernel receives a GPF when it attempts to write
into MSR_K7_PERFCTR, which causes an OOPs.

The patch fixes it by just "fake" emulating the appropriate MSRs, throwing away
the data in the process.  This causes the NMI watchdog to not actually work, but
it's not such a big deal in a virtualized environment.

Tested by myself on a RHEL-4 guest, and Joerg Roedel on a Windows XP 64-bit 
guest.

Signed-off-by: Chris Lalancette <[EMAIL PROTECTED]>
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 89e0be2..6130704 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -1284,16 +1284,18 @@ static int svm_set_msr(struct kvm_vcpu *vcpu, unsigned ecx, u64 data)
 	case MSR_K7_EVNTSEL1:
 	case MSR_K7_EVNTSEL2:
 	case MSR_K7_EVNTSEL3:
+	case MSR_K7_PERFCTR0:
+	case MSR_K7_PERFCTR1:
+	case MSR_K7_PERFCTR2:
+	case MSR_K7_PERFCTR3:
 		/*
-		 * only support writing 0 to the performance counters for now
-		 * to make Windows happy. Should be replaced by a real
-		 * performance counter emulation later.
+		 * Just discard all writes to the performance counters; this
+		 * should keep both older linux and windows 64-bit guests
+		 * happy
 		 */
-		if (data != 0)
-			goto unhandled;
+
 		break;
 	default:
-	unhandled:
 		return kvm_set_msr_common(vcpu, ecx, data);
 	}
 	return 0;
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH]: Fix MSR_K7_EVNTSEL{0,3} for SVM

2008-04-28 Thread Andi Kleen

Chris Lalancette <[EMAIL PROTECTED]> writes:
> this allows my RHEL-4 guest to successfully boot, although obviously the NMI
> watchdog which it thinks it set up is not actually working.

That's fine. On a virtualized environment you don't really need a NMI watchdog
because you can always debug from the outside

-Andi

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH]: Fix MSR_K7_EVNTSEL{0,3} for SVM

2008-04-28 Thread Chris Lalancette

Joerg Roedel wrote:
>>  OK, yeah, I read some of those threads over the weekend.  It is a larger
>> problem than just this crash, and probably one to be solved later.
>>  I have attached a patch which just discards all writes, as you 
>> suggested;
>> this allows my RHEL-4 guest to successfully boot, although obviously the NMI
>> watchdog which it thinks it set up is not actually working.  Joerg, can you 
>> test
>> this on your 64-bit Windows XP guest to make sure it is still working?
> 
> XP 64 bit installs and works fine with your patch.

Great, thanks for testing, I'll post the patch again with a proper changelog for
Avi.

Chris Lalancette

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] kvm: how big is type?

Izik Eidus wrote:
> Avi Kivity wrote:
>   
>> Harvey Harrison wrote:
>> 
>>> arch/x86/kvm/x86.c:3484:25: warning: cast truncates bits from constant
>>> value (100 becomes 0)
>>> arch/x86/kvm/x86.c:3510:24: warning: cast truncates bits from constant
>>> value (100 becomes 0)
>>>
>>> The problem:
>>> cseg_desc.type &= ~(1 << 8); //clear the B flag
>>> nseg_desc.type |= (1 << 8);
>>>
>>> type is a 4-bit bitfield on x86please look into this.
>>>
>>>   
>>>   
>> I think it ought to be (1 << 1), not (1 << 8), as it refers to the
>> "busy" bit of the task type.  Izik?
>>
>>
>> 
> From cf6e76c69a38a983df0c84a3dcc2336042eb3436 Mon Sep 17 00:00:00 2001
> From: Izik Eidus <[EMAIL PROTECTED]>
> Date: Mon, 28 Apr 2008 18:16:08 +0300
> Subject: [PATCH] KVM: x86: task switch: fix wrong bit setting for the busy 
> flag.
>  the busy bit is in offset of 1 inside type and not in 8.
>   

Applied, thanks.


-- 
error compiling committee.c: too many arguments to function


-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH]: Fix MSR_K7_EVNTSEL{0,3} for SVM

2008-04-28 Thread Отдел документооборота

On Mon, Apr 28, 2008 at 10:17:37AM -0400, Chris Lalancette wrote:
> Joerg Roedel wrote:
> > We already discussed the emulation of the performance counter registers
> > in the past. The conclusion is, that we loose live migration with that
> > emulation because performance monitoring is implemented differently
> > between AMD and Intel systems. Maybe discarding _any_ writes to
> > the performance counter MSRs will fix the guest crash. What we should
> > not do is injecting GPF on zero writes to the MSRs because that will
> > break Windows XP 64bit installation.
> 
>  OK, yeah, I read some of those threads over the weekend.  It is a larger
> problem than just this crash, and probably one to be solved later.
>  I have attached a patch which just discards all writes, as you suggested;
> this allows my RHEL-4 guest to successfully boot, although obviously the NMI
> watchdog which it thinks it set up is not actually working.  Joerg, can you 
> test
> this on your 64-bit Windows XP guest to make sure it is still working?

XP 64 bit installs and works fine with your patch.

Joerg


-- 
   |   AMD Saxony Limited Liability Company & Co. KG
 Operating | Wilschdorfer Landstr. 101, 01109 Dresden, Germany
 System|  Register Court Dresden: HRA 4896
 Research  |  General Partner authorized to represent:
 Center| AMD Saxony LLC (Wilmington, Delaware, US)
   | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy


-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] kvm: how big is type?

2008-04-28 Thread Izik Eidus

Avi Kivity wrote:
> Harvey Harrison wrote:
>> arch/x86/kvm/x86.c:3484:25: warning: cast truncates bits from constant
>> value (100 becomes 0)
>> arch/x86/kvm/x86.c:3510:24: warning: cast truncates bits from constant
>> value (100 becomes 0)
>>
>> The problem:
>> cseg_desc.type &= ~(1 << 8); //clear the B flag
>> nseg_desc.type |= (1 << 8);
>>
>> type is a 4-bit bitfield on x86please look into this.
>>
>>   
> 
> I think it ought to be (1 << 1), not (1 << 8), as it refers to the
> "busy" bit of the task type.  Izik?
> 
> 
>From cf6e76c69a38a983df0c84a3dcc2336042eb3436 Mon Sep 17 00:00:00 2001
From: Izik Eidus <[EMAIL PROTECTED]>
Date: Mon, 28 Apr 2008 18:16:08 +0300
Subject: [PATCH] KVM: x86: task switch: fix wrong bit setting for the busy flag.
 the busy bit is in offset of 1 inside type and not in 8.

Signed-off-by: Izik Eidus <[EMAIL PROTECTED]>
---
 arch/x86/kvm/x86.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 0ce5563..5c360bb 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3481,7 +3481,7 @@ int kvm_task_switch(struct kvm_vcpu *vcpu, u16 
tss_selector, int reason)
}
 
if (reason == TASK_SWITCH_IRET || reason == TASK_SWITCH_JMP) {
-   cseg_desc.type &= ~(1 << 8); //clear the B flag
+   cseg_desc.type &= ~(1 << 1); //clear the B flag
save_guest_segment_descriptor(vcpu, tr_seg.selector,
  &cseg_desc);
}
@@ -3507,7 +3507,7 @@ int kvm_task_switch(struct kvm_vcpu *vcpu, u16 
tss_selector, int reason)
}
 
if (reason != TASK_SWITCH_IRET) {
-   nseg_desc.type |= (1 << 8);
+   nseg_desc.type |= (1 << 1);
save_guest_segment_descriptor(vcpu, tss_selector,
  &nseg_desc);
}
-- 
1.5.3.6


-- 
woof.

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] mmu notifier #v14

2008-04-28 Thread Marcelo Tosatti

Hi Andrea,

Looks good.

Acked-by: Marcelo Tosatti <[EMAIL PROTECTED]>


-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] Договоры организации с физ. ли цами

Бухгалтеру o дoгoвoрнoй рабoте oрганизации - правoвые oснoвы и налoгoвый аспект
7 мая 2008, г. Мoсква

Прoграмма семинара

1. Как правильнo oфoрмить дoгoвoр, oбязательные и дoпoлнительные услoвия
дoгoвoрoв. Кoгда мoжнo считать сoблюденнoй прoстую письменную фoрму дoгoвoра.
Кoгда дoгoвoр требует гoсударственнoй регистрации или нoтариальнoгo заверения.
Рамoчные дoгoвoры. oферта (oднoстoрoннее предлoжение заключить сделку).
Пoдписание дoгoвoра.
2. Гарантийные услoвия в дoгoвoрах - залoг, задатoк, неустoйка (налoгoвые
преимущества гарантий пo сравнению с авансами пo дoгoвoру). Регулирoвание в
дoгoвoрах и ╚пo умoлчанию╩ вoпрoсoв вoзмещения ущерба oт неиспoлнения дoгoвoра.
Упущенная выгoда. Ничтoжнoсть прoтивoзакoнных услoвий сделoк и ее налoгoвые
пoследствия.
3. Разрешение спoрoв пo дoгoвoрам. Претензиoнная рабoта. Признание дoлга
сoмнительным, безнадежным, списание дoлга. Срoки искoвoй давнoсти.
4. Цена в дoгoвoре - спoсoбы oбoзначения (дoлжна ли быть указана oпределенная
цена), единицы изменения (рубли, инoстранная валюта, услoвные единицы),
oбoснoвание рынoчнoй цены. Скидки - разoвые и накoпительные - пoрядoк
предoставления и учета.
5. Пoрядoк расчетoв пo дoгoвoру, наличные и безналичные платежи с учетoм
изменений пoрядка расчета наличными сoгласнo Указанию ЦБ oт 20.06.2007 N 1843-У
"o предельнoм размере расчетoв наличными деньгами и расхoдoвании наличных
денег, пoступивших в кассу юридическoгo лица или кассу индивидуальнoгo
предпринимателя". Даты признания дoхoдoв и расхoдoв пo дoгoвoрам. Расчетные
дoкументы в рублях, валюте, услoвных единицах. Сoпрoвoдительные и расчетные
дoкументы в электрoннoм виде. Акты: oбязательнo ли сoставлять акт, ждать ли
oкoнчания дoгoвoра или сoставлять акт пoэтапнo, фoрма акта, пoзиция Минфина
oтнoсительнo пoрядка запoлнения актoв и детализации сведений в них.
6. Дoгoвoры между юридическими лицами - oфoрмление, учет и налoгooблoжение.
Зависимoсть налoгoвoгo бремени oт вида и сoдержания дoгoвoра. Дoгoвoр и налoг
на прибыль. Дoгoвoр и НДС.
- дoгoвoр купли-прoдажи (предмет, oбязательные услoвия, oфoрмление и
пoследствия вoзврата тoвара),
- дoгoвoр мены (oбмен и мена - в чем oтличия, рынoчная цена сделки),
- дoгoвoр аренды (регистрация дoгoвoрoв, аренда автoтранспoртнoгo средства,
аренда oфиса),
- дoгoвoр страхoвания (личнoе и имущественнoе страхoвание, страхoвание
oтветственнoсти, налoгoвые льгoты),
- дoгoвoры займа (признание расхoдoв, беспрoцентные займы),
- дoгoвoры безвoзмезднoй передачи и безвoзмезднoгo пoльзoвания (oграничения в
сфере применения и признания расхoдoв),
- пoсреднические дoгoвoры (oсoбеннoсти дoгoвoрoв кoмиссии, агентирoвания,
пoручения),
- дoгoвoр прoстoгo тoварищества (участники, налoгoвые преимущества, дoля
участника и распределение расхoдoв и дoхoдoв),
- дoгoвoр вoзмезднoгo oказания услуг (существенные услoвия дoгoвoра,
разнoвиднoсти дoгoвoрoв услуг, преимущества перед дoгoвoрoм пoдряда).
6. Дoгoвoры oрганизации с физическими лицами: кoллективные, трудoвые,
гражданскo-правoвые, дoгoвoры с индивидуальными предпринимателями - учет и
налoгooблoжение, выплаты пo таким дoгoвoрам. Вoзмoжнoсть управления налoгoвoй
нагрузкoй на предприятие с пoмoщью таких дoгoвoрoв.

Пpoдoлжительнoсть oбучения: с 10 дo 17 часoв (с пеpеpывoм на oбед и кoфе-паузу).
Местo oбучения: г. Мoсква, 5 мин. пешкoм oт м. Академическая.
Стoимoсть oбучения: 4900 pуб. (с НДС).
(В стoимoсть вxoдит: pаздатoчный матеpиал, кoфе-пауза, oбед в pестopане).

Пpи oтсутствии вoзмoжнoсти пoсетить семинаp, мы пpедлагаем пpиoбpести егo
видеoвеpсию на DVD/CD дискаx или видеoкассетаx (пpилагается автopский
pаздатoчный матеpиал).
Цена видеoкуpса - 3500 pублей, с учетoм НДС.

Для pегистpации на семинаp неoбxoдимo oтпpавить нам пo факсу: pеквизиты
opганизации, тему и дату семинаpа, пoлнoе ФИo участникoв, кoнтактный телефoн и
факс.
Для заказа видеoкуpса неoбxoдимo oтпpавить нам пo факсу: pеквизиты opганизации,
тему видеoкуpса, указать нoситель (ДВД или СД диски), телефoн, факс, кoнтактнoе
лицo и тoчный адpес дoставки.

Пoлучить дoпoлнительную инфopмацию и заpегистpиpoваться мoжнo:
пo т/ф: ( 4 9 5 ) 54 3 - 8 8 - 4 6

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] Have hot lovemaking every night

2008-04-28 Thread GARRETT

Be a better lover by strengthening your manhood for the good of womankind. 
http://www.driksil.com/

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH]: Fix MSR_K7_EVNTSEL{0,3} for SVM

2008-04-28 Thread Chris Lalancette

Joerg Roedel wrote:
> We already discussed the emulation of the performance counter registers
> in the past. The conclusion is, that we loose live migration with that
> emulation because performance monitoring is implemented differently
> between AMD and Intel systems. Maybe discarding _any_ writes to
> the performance counter MSRs will fix the guest crash. What we should
> not do is injecting GPF on zero writes to the MSRs because that will
> break Windows XP 64bit installation.

 OK, yeah, I read some of those threads over the weekend.  It is a larger
problem than just this crash, and probably one to be solved later.
 I have attached a patch which just discards all writes, as you suggested;
this allows my RHEL-4 guest to successfully boot, although obviously the NMI
watchdog which it thinks it set up is not actually working.  Joerg, can you test
this on your 64-bit Windows XP guest to make sure it is still working?

Thanks,
Chris Lalancette
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 89e0be2..6130704 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -1284,16 +1284,18 @@ static int svm_set_msr(struct kvm_vcpu *vcpu, unsigned ecx, u64 data)
 	case MSR_K7_EVNTSEL1:
 	case MSR_K7_EVNTSEL2:
 	case MSR_K7_EVNTSEL3:
+	case MSR_K7_PERFCTR0:
+	case MSR_K7_PERFCTR1:
+	case MSR_K7_PERFCTR2:
+	case MSR_K7_PERFCTR3:
 		/*
-		 * only support writing 0 to the performance counters for now
-		 * to make Windows happy. Should be replaced by a real
-		 * performance counter emulation later.
+		 * Just discard all writes to the performance counters; this
+		 * should keep both older linux and windows 64-bit guests
+		 * happy
 		 */
-		if (data != 0)
-			goto unhandled;
+
 		break;
 	default:
-	unhandled:
 		return kvm_set_msr_common(vcpu, ecx, data);
 	}
 	return 0;
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH]: Fix MSR_K7_EVNTSEL{0,3} for SVM

On Fri, Apr 25, 2008 at 02:43:19PM -0400, Chris Lalancette wrote:
> Unfortunately, we can't just "fake emulate" MSR_K7_PERFCTR[0-3] like we are
> doing for MSR_K7_EVNTSEL[0-3]; if they are there, linux expects to be able to
> put values into them.  I think the correct solution here is to emulate
> MSR_K7_PERFCTR[0-3] and MSR_K7_EVNTSEL[0-3] for real.  I'm working on a patch 
> to
> do this now.

We already discussed the emulation of the performance counter registers
in the past. The conclusion is, that we loose live migration with that
emulation because performance monitoring is implemented differently
between AMD and Intel systems. Maybe discarding _any_ writes to
the performance counter MSRs will fix the guest crash. What we should
not do is injecting GPF on zero writes to the MSRs because that will
break Windows XP 64bit installation.

Joerg

-- 
   |   AMD Saxony Limited Liability Company & Co. KG
 Operating | Wilschdorfer Landstr. 101, 01109 Dresden, Germany
 System|  Register Court Dresden: HRA 4896
 Research  |  General Partner authorized to represent:
 Center| AMD Saxony LLC (Wilmington, Delaware, US)
   | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH 0/4] paravirt clock patches

2008-04-28 Thread Gerd Hoffmann

Avi Kivity wrote:
> The patches look good, but pleasy copy Jeremy and virtualization@ for
> patches which touch things outside kvm.

Will do for the next round.

> It's perhaps better to reverse the order: first fix kvm to be
> compatible, then merge the Xen and kvm implementations into a single one.

Fixing kvm (guest side) would be copying parts of the xen guest code, so
that doesn't make much sense to me ...

cheers,
  Gerd

-- 
http://kraxel.fedorapeople.org/xenner/

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] [ kvm-Bugs-1953353 ] could not load PC BIOS '/path/to/bios.bin' on "-m 4096"

Bugs item #1953353, was opened at 2008-04-28 13:50
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1953353&group_id=180599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Rafal Wijata (ravpl)
Assigned to: Nobody/Anonymous (nobody)
Summary: could not load PC BIOS '/path/to/bios.bin' on "-m 4096"

Initial Comment:
The maximum amount of memory I can give to kvm is ~3560M

I run custom compiled kvm-66 on F8 box with
Linux mailhub 2.6.24.4-64.fc8 #1 SMP Sat Mar 29 09:15:49 EDT 2008 x86_64 x86_64 
x86_64 GNU/Linux
The modules are loaded from F8 kernel, rather than those shipped with kvm-66

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1953353&group_id=180599

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] [ kvm-Bugs-1850037 ] SMP 8-way doesn't works, and returns incorrect error

Bugs item #1850037, was opened at 2007-12-13 14:25
Message generated for change (Comment added) made by ravpl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1850037&group_id=180599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Technologov (technologov)
Assigned to: Nobody/Anonymous (nobody)
Summary: SMP 8-way doesn't works, and returns incorrect error

Initial Comment:
Host: AMD Barcelona, 8-way SMP (Octo Core), 8 GB of RAM, Fedora 7/x64. KVM-56.

[EMAIL PROTECTED] scripts]$ ./qemu-kvm -hda 
/isos/disks-vm/alexeye/openSUSE-10.3-test32.vmdk -cdrom 
/isos/openSuse-10.3-GM-x86_64.iso -m 9000 -smp 8 -boot d
(VMDK) image open: flags=0x2 
filename=/isos/disks-vm/alexeye/openSUSE-10.3-test32.vmdk
kvm_create_vcpu: Invalid argument
kvm_create_vcpu: Invalid argument
kvm_run: Bad file descriptor
kvm_create_vcpu: Invalid argument
kvm_run returned -9
kvm_create_vcpu: Invalid argument

[EMAIL PROTECTED] scripts]$ free
 total   used   free sharedbuffers cached
Mem:   82556488213812  41836  0  553766573508
-/+ buffers/cache:15849286670720
Swap:  4194288  04194288

Output of dmesg:
SIPI to vcpu 1 vector 0x10
SIPI to vcpu 2 vector 0x10
SIPI to vcpu 3 vector 0x10
kvm: 16024: cpu0 unhandled rdmsr: 0x417
Ignoring de-assert INIT to vcpu 1
SIPI to vcpu 1 vector 0x06
SIPI to vcpu 1 vector 0x06
kvm: 16024: cpu1 unhandled rdmsr: 0x417
Ignoring de-assert INIT to vcpu 2
SIPI to vcpu 2 vector 0x06
SIPI to vcpu 2 vector 0x06
kvm: 16024: cpu2 unhandled rdmsr: 0x417
Ignoring de-assert INIT to vcpu 3
SIPI to vcpu 3 vector 0x06
SIPI to vcpu 3 vector 0x06
kvm: 16024: cpu3 unhandled rdmsr: 0x417
Machine check events logged

==

Expected Behavior:
It must either work, or return proper error message, that SMP beyond 4-way is 
not supported.

-Alexey "Technologov", 13.12.2007.

--

Comment By: Rafal Wijata (ravpl)
Date: 2008-04-28 13:44

Message:
Logged In: YES 
user_id=996150
Originator: NO

I have dual quad core
model name  : Intel(R) Xeon(R) CPU   E5420  @ 2.50GHz
and can confirm, that I can't run kvm with more than 4 vcpus.
I run custom compiled kvm-66 on Linux mailhub 2.6.24.4-64.fc8 #1 SMP Sat
Mar 29 09:15:49 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux
Modules are from FC8 rather than kvm-66.

Browsing kvm sources showed static array for 16 cpus. Maybe those four it
kernel's module limit?

--

Comment By: Technologov (technologov)
Date: 2008-02-26 14:28

Message:
Logged In: YES 
user_id=1839746
Originator: YES

FIXED in KVM-62.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1850037&group_id=180599

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] kvm: how big is type?

Harvey Harrison wrote:
> arch/x86/kvm/x86.c:3484:25: warning: cast truncates bits from constant value 
> (100 becomes 0)
> arch/x86/kvm/x86.c:3510:24: warning: cast truncates bits from constant value 
> (100 becomes 0)
>
> The problem:
>   cseg_desc.type &= ~(1 << 8); //clear the B flag
>   nseg_desc.type |= (1 << 8);
>
> type is a 4-bit bitfield on x86please look into this.
>
>   

I think it ought to be (1 << 1), not (1 << 8), as it refers to the 
"busy" bit of the task type.  Izik?

-- 
error compiling committee.c: too many arguments to function

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH 8/8] KVM: VMX: Enable EPT feature for KVM

Yang, Sheng wrote:
> The updated patch also moved ept_load_pdptrs() from critical region to 
> kvm_handle_vmexit().
>
>   

Thanks; applied all EPT patches.

-- 
error compiling committee.c: too many arguments to function

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] [ANNOUNCE] kvm-67 release