[KVM-AUTOTEST][PATCH] kvm_runtest_2.py: print exception info with kvm_log.error().
From: Michael Goldish mgold...@redhat.com We do this so that tests don't have to print the exception info themselves. Signed-off-by: Michael Goldish mgold...@redhat.com Signed-off-by: Uri Lublin u...@redhat.com diff --git a/client/tests/kvm_runtest_2/kvm_runtest_2.py b/client/tests/kvm_runtest_2/kvm_runtest_2.py index f3eb350..fda7282 100644 --- a/client/tests/kvm_runtest_2/kvm_runtest_2.py +++ b/client/tests/kvm_runtest_2/kvm_runtest_2.py @@ -93,7 +93,8 @@ class kvm_runtest_2(test.test): env.sync() except Exception, e: -kvm_log.debug(Test failed (%s); postprocessing on error... % e) +kvm_log.error(Test failed: %s % e) +kvm_log.debug(Postprocessing on error...) kvm_preprocessing.postprocess_on_error(self, params, env) env.sync() raise -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[KVM-AUTOTEST][PATCH] RHEL-4.7-i386.steps: make the installation boot faster.
From: Michael Goldish mgold...@redhat.com Add an initial step that detects the first boot screen and hits ENTER. Currently we wait for a timeout to expire, which takes a while. Signed-off-by: Michael Goldish mgold...@redhat.com diff --git a/client/tests/kvm_runtest_2/steps/RHEL-4.7-i386.steps b/client/tests/kvm_runtest_2/steps/RHEL-4.7-i386.steps index a74d0b4..3816c15 100644 --- a/client/tests/kvm_runtest_2/steps/RHEL-4.7-i386.steps +++ b/client/tests/kvm_runtest_2/steps/RHEL-4.7-i386.steps @@ -2,6 +2,12 @@ # Generated on Tue Mar 10 09:50:26 2009 # uname -a: Linux dhcp74-230.virt.bos.redhat.com 2.6.18-128.el5 #1 SMP Wed Dec 17 11:41:38 EST 2008 x86_64 x86_64 x86_64 GNU/Linux # +step unknown +screendump 20090413_013526_868fe81019ae64a0b066c4c0d4ebc4e1.ppm +barrier_2 188 30 354 265 48ef114b5a42ba0d5bebfaee47dce498 50 +# Sending keys: ret +key ret +# step 223.57 screendump 20080101_01_48539713881a206003b29551621b6e2d.ppm # skip cd check -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[KVM-AUTOTEST][PATCH] kvm_tests.py: do not explicitly print reason for failure.
From: Michael Goldish mgold...@redhat.com No need to print the reason in the test itself -- kvm_runtest_2.py takes care of this now. Specifically, replace blocks such as: message = Error message kvm_log.error(message) raise error.TestFail, message with: raise error.TestFail, Error message Signed-off-by: Michael Goldish mgold...@redhat.com diff --git a/client/tests/kvm_runtest_2/kvm_tests.py b/client/tests/kvm_runtest_2/kvm_tests.py index e743b74..8825884 100644 --- a/client/tests/kvm_runtest_2/kvm_tests.py +++ b/client/tests/kvm_runtest_2/kvm_tests.py @@ -12,21 +12,15 @@ import scan_results def run_boot(test, params, env): vm = kvm_utils.env_get_vm(env, params.get(main_vm)) if not vm: -message = VM object not found in environment -kvm_log.error(message) -raise error.TestError, message +raise error.TestError, VM object not found in environment if not vm.is_alive(): -message = VM seems to be dead; Test requires a living VM -kvm_log.error(message) -raise error.TestError, message +raise error.TestError, VM seems to be dead; Test requires a living VM kvm_log.info(Waiting for guest to be up...) session = kvm_utils.wait_for(vm.ssh_login, 240, 0, 2) if not session: -message = Could not log into guest -kvm_log.error(message) -raise error.TestFail, message +raise error.TestFail, Could not log into guest kvm_log.info(Logged in) @@ -35,9 +29,7 @@ def run_boot(test, params, env): kvm_log.info(Reboot command sent; waiting for guest to go down...) if not kvm_utils.wait_for(lambda: not session.is_responsive(), 120, 0, 1): -message = Guest refuses to go down -kvm_log.error(message) -raise error.TestFail, message +raise error.TestFail, Guest refuses to go down session.close() @@ -45,9 +37,7 @@ def run_boot(test, params, env): session = kvm_utils.wait_for(vm.ssh_login, 120, 0, 2) if not session: -message = Could not log into guest after reboot -kvm_log.error(message) -raise error.TestFail, message +raise error.TestFail, Could not log into guest after reboot kvm_log.info(Guest is up again) @@ -58,24 +48,16 @@ def run_migration(test, params, env): src_vm_name = params.get(migration_src) vm = kvm_utils.env_get_vm(env, src_vm_name) if not vm: -message = VM '%s' not found in environment % src_vm_name -kvm_log.error(message) -raise error.TestError, message +raise error.TestError, VM '%s' not found in environment % src_vm_name if not vm.is_alive(): -message = VM '%s' seems to be dead; Test requires a living VM % src_vm_name -kvm_log.error(message) -raise error.TestError, message +raise error.TestError, VM '%s' seems to be dead; Test requires a living VM % src_vm_name dest_vm_name = params.get(migration_dst) dest_vm = kvm_utils.env_get_vm(env, dest_vm_name) if not dest_vm: -message = VM '%s' not found in environment % dest_vm_name -kvm_log.error(message) -raise error.TestError, message +raise error.TestError, VM '%s' not found in environment % dest_vm_name if not dest_vm.is_alive(): -message = VM '%s' seems to be dead; Test requires a living VM % dest_vm_name -kvm_log.error(message) -raise error.TestError, message +raise error.TestError, VM '%s' seems to be dead; Test requires a living VM % dest_vm_name pre_scrdump_filename = os.path.join(test.debugdir, migration_pre.ppm) post_scrdump_filename = os.path.join(test.debugdir, migration_post.ppm) @@ -83,18 +65,14 @@ def run_migration(test, params, env): # See if migration is supported s, o = vm.send_monitor_cmd(help info) if not info migrate in o: -message = Migration is not supported -kvm_log.error(message) -raise error.TestError, message +raise error.TestError, Migration is not supported # Log into guest and get the output of migration_test_command kvm_log.info(Waiting for guest to be up...) session = kvm_utils.wait_for(vm.ssh_login, 240, 0, 2) if not session: -message = Could not log into guest -kvm_log.error(message) -raise error.TestFail, message +raise error.TestFail, Could not log into guest kvm_log.info(Logged in) @@ -110,9 +88,8 @@ def run_migration(test, params, env): # Migrate s, o = vm.send_monitor_cmd(cmd) if s: -message = Migration command failed -kvm_log.error(message + \n(command: '%r', output: '%r') % (cmd, o)) -raise error.TestFail, message +kvm_log.error(Migration command failed (command: %r, output: %r) % (cmd, o)) +raise error.TestFail, Migration command failed # Define some helper functions def
[KVM-AUTOTEST][PATCH] kvm_tests.py: print output of migration_test_command only upon failure.
From: Michael Goldish mgold...@redhat.com Print outputs (before and after migration) of migration_test_command only if they differ. Currently we print them anyway, and the outputs can be very long. Signed-off-by: Michael Goldish mgold...@redhat.com diff --git a/client/tests/kvm_runtest_2/kvm_tests.py b/client/tests/kvm_runtest_2/kvm_tests.py index 9733dc1..7349524 100644 --- a/client/tests/kvm_runtest_2/kvm_tests.py +++ b/client/tests/kvm_runtest_2/kvm_tests.py @@ -80,8 +80,6 @@ def run_migration(test, params, env): reference_output = session.get_command_output(params.get(migration_test_command)) session.close() -kvm_log.info(Reference output of command '%s':\n%s % (params.get(migration_test_command), reference_output)) - # Define the migration command cmd = migrate -d tcp:localhost:%d % dest_vm.migration_port kvm_log.debug(Migration command: %s % cmd) @@ -162,11 +160,13 @@ def run_migration(test, params, env): output = session.get_command_output(params.get(migration_test_command)) session.close() -kvm_log.info(Output of command '%s' after migration:\n%s % (params.get(migration_test_command), output)) - # Compare output to reference output if output != reference_output: -raise error.TestFail, Command output before and after migration differs +kvm_log.info(Command output before migration differs from command output after migration) +kvm_log.info(Command: %s % params.get(migration_test_command)) +kvm_log.info(Output before: %s % reference_output) +kvm_log.info(Output after: %s % output) +raise error.TestFail, Command produced different output before and after migration def run_autotest(test, params, env): -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[KVM-AUTOTEST][PATCH] kvm_tests.py: run_boot(): get 'cmd_reboot' from VM params, not test params.
From: Michael Goldish mgold...@redhat.com 'cmd_reboot' is a VM param, so get it using vm.get_params().get(cmd_reboot). Currently it is taken from the test params. This is a mistake. Signed-off-by: Michael Goldish mgold...@redhat.com diff --git a/client/tests/kvm_runtest_2/kvm_tests.py b/client/tests/kvm_runtest_2/kvm_tests.py index 8825884..9733dc1 100644 --- a/client/tests/kvm_runtest_2/kvm_tests.py +++ b/client/tests/kvm_runtest_2/kvm_tests.py @@ -25,7 +25,8 @@ def run_boot(test, params, env): kvm_log.info(Logged in) if params.get(reboot) == yes: -session.sendline(params.get(cmd_reboot)) +# Send the VM's reboot command +session.sendline(vm.get_params().get(cmd_reboot)) kvm_log.info(Reboot command sent; waiting for guest to go down...) if not kvm_utils.wait_for(lambda: not session.is_responsive(), 120, 0, 1): -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[KVM-AUTOTEST][PATCH] Add WinXP.64 and Win2003.64 guests.
From: Alexey Eromenko aerom...@redhat.com 1. Add variants for WinXP.64 and Win2003.64 to kvm_tests.cfg.sample. 2. Convert WinXP.64 and Win2003.64 step files to the new format. Signed-off-by: Alexey Eromenko aerom...@redhat.com Signed-off-by: Michael Goldish mgold...@redhat.com Signed-off-by: Uri Lublin u...@redhat.com diff --git a/client/tests/kvm_runtest_2/kvm_tests.cfg.sample b/client/tests/kvm_runtest_2/kvm_tests.cfg.sample index 942f07e..72e4443 100644 --- a/client/tests/kvm_runtest_2/kvm_tests.cfg.sample +++ b/client/tests/kvm_runtest_2/kvm_tests.cfg.sample @@ -278,46 +278,73 @@ variants: install: steps = Win2000-32.steps cdrom = windows/Windows2000_sp4.iso -md5sum=dda6039f3a9173f0f6bfae40f5efdfea -md5sum_1m=dd28fba196d366d56fe774bd93df5527 +md5sum = dda6039f3a9173f0f6bfae40f5efdfea +md5sum_1m = dd28fba196d366d56fe774bd93df5527 user = user cdkey = WIN_2000_32_CDKEY setup: steps = Win2000-32-setupssh.steps cdrom = windows/setupssh.iso -- WinXP: +- WinXP.32: image_name = winXP-32 install: steps = WinXP-32.steps cdrom = windows/WindowsXP-sp2-vlk.iso -md5sum_1m=b473bf75af2d1269fec8958cf0202bfd +md5sum = 743450644b1d9fe97b3cf379e22dceb0 +md5sum_1m = b473bf75af2d1269fec8958cf0202bfd user = user cdkey = WIN_XP_32_CDKEY setup: steps = WinXP-32-setupssh.steps cdrom = windows/setupssh.iso +- WinXP.64: +only install +image_name = winXP-64 +install: +steps = WinXP-64.steps +cdrom = windows/WindowsXP-64.iso +md5sum = 8d3f007ec9c2060cec8a50ee7d7dc512 +md5sum_1m = e812363ff427effc512b7801ee70e513 +user = user +cdkey = WIN_XP_64_CDKEY + - Win2003: -image_name = win2003-32 image_size = 20G cmd_shutdown = shutdown /s /f /t 0 cmd_reboot = shutdown /r /f /t 0 -install: -steps = Win2003-32.steps -cdrom = windows/Windows2003_r2_VLK.iso -md5sum=03e921e9b4214773c21a39f5c3f42ef7 -md5sum_1m=37c2fdec15ac4ec16aa10fdfdb338aa3 -user = user -cdkey = WIN_2003_32_CDKEY -setup: -steps = Win2003-32-setupssh.steps -cdrom = windows/setupssh.iso + +variants: +- 32: +image_name = win2003-32 +install: +steps = Win2003-32.steps +cdrom = windows/Windows2003_r2_VLK.iso +md5sum = 03e921e9b4214773c21a39f5c3f42ef7 +md5sum_1m = 37c2fdec15ac4ec16aa10fdfdb338aa3 +user = user +cdkey = WIN_2003_32_CDKEY +setup: +steps = Win2003-32-setupssh.steps +cdrom = windows/setupssh.iso + +- 64: +only install +image_name = win2003-64 +install: +steps = Win2003-64.steps +cdrom = windows/Windows2003-x64.iso +md5sum = 5703f87c9fd77d28c05ffadd3354dbbd +md5sum_1m = 439393c384116aa09e08a0ad047dcea8 +user = user +cdkey = WIN_2003_64_CDKEY - WinVista: only install image_name = winvista image_size = 20G + variants: - 32: image_name += -32 @@ -325,6 +352,7 @@ variants: cdrom = windows/WindowsVista-32.iso md5sum = 1008f323d5170c8e614e52ccb85c0491 md5sum_1m = c724e9695da483bc0fd59e426eaefc72 + - 64: image_name += -64 steps = Win-Vista-64.steps @@ -342,6 +370,7 @@ variants: use_telnet = yes username = Administrator password = 1q2w3eP + variants: - 32: image_name += -32 @@ -353,6 +382,7 @@ variants: setup: steps =
[KVM-AUTOTEST][PATCH] kvm_tests.cfg.sample: Add virtio block device variant.
From: Alexey Eromenko aerom...@redhat.com 1. Add virtio block device variant 'virtio_blk' next to 'ide' and 'scsi'. 2. Filter out unsupported guests. Signed-off-by: Alexey Eromenko aerom...@redhat.com Signed-off-by: Michael Goldish mgold...@redhat.com Signed-off-by: Uri Lublin u...@redhat.com diff --git a/client/tests/kvm_runtest_2/kvm_tests.cfg.sample b/client/tests/kvm_runtest_2/kvm_tests.cfg.sample index 72e4443..a38669d 100644 --- a/client/tests/kvm_runtest_2/kvm_tests.cfg.sample +++ b/client/tests/kvm_runtest_2/kvm_tests.cfg.sample @@ -445,12 +445,10 @@ variants: md5sum = 9fae22f2666369968a76ef59e9a81ced -e1000|virtio: -only Fedora.9 openSUSE-11 Ubuntu-8.10-server - linux_s3: only Linux + variants: - @up: - smp2: @@ -476,6 +474,13 @@ variants: - scsi: drive_format=scsi image_boot=yes +- virtio_blk: +drive_format=virtio +image_boot=yes + + +virtio|virtio_blk|e1000: +only Fedora.9 openSUSE-11 Ubuntu-8.10-server variants: -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[KVM-AUTOTEST][PATCH] kvm_tests.cfg: Windows guests: find ssh/telnet iso under windows directory
From: Uri Lublin u...@redhat.com Not under linux directory. Signed-off-by: Uri Lublin u...@redhat.com diff --git a/client/tests/kvm_runtest_2/kvm_tests.cfg.sample b/client/tests/kvm_runtest_2/kvm_tests.cfg.sample index 8227b5f..942f07e 100644 --- a/client/tests/kvm_runtest_2/kvm_tests.cfg.sample +++ b/client/tests/kvm_runtest_2/kvm_tests.cfg.sample @@ -312,7 +312,7 @@ variants: cdkey = WIN_2003_32_CDKEY setup: steps = Win2003-32-setupssh.steps -cdrom = linux/setupssh.iso +cdrom = windows/setupssh.iso - WinVista: only install @@ -352,7 +352,7 @@ variants: md5sum_1m=07d7f5006393f74dc76e6e2e943e2440 setup: steps = Win2008-32-setuptelnet.steps -cdrom = linux/setuptelnet.iso +cdrom = windows/setuptelnet.iso - 64: image_name += -64 install: @@ -363,7 +363,7 @@ variants: passwd = 1q2w3eP setup: steps = Win2008-32-setuptelnet.steps -cdrom = linux/setuptelnet.iso +cdrom = windows/setuptelnet.iso # Unix/BSD section - @Unix: -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[KVM-AUTOTEST][PATCH] kvm_utils.py, kvm_vm.py: print debugging info upon command failure.
From: Michael Goldish mgold...@redhat.com In VM.send_monitor_cmd(), kvm_spawn.get_command_status_output() and kvm_spawn.read_until_output_matches(), print some information upon failure (exit status and/or output so far). Also add function kvm_utils.format_str_for_message() which helps in formatting these debug messages. Also print the command being executed with get_command_status_output(). Signed-off-by: Michael Goldish mgold...@redhat.com diff --git a/client/tests/kvm_runtest_2/kvm_utils.py b/client/tests/kvm_runtest_2/kvm_utils.py index 594105a..be8ad95 100644 --- a/client/tests/kvm_runtest_2/kvm_utils.py +++ b/client/tests/kvm_runtest_2/kvm_utils.py @@ -217,6 +217,7 @@ class kvm_spawn: match = None data = + end_time = time.time() + timeout while time.time() end_time: # Read data from child @@ -238,6 +239,11 @@ class kvm_spawn: # Are we done? if done: break +# Print some debugging info +if match == None and self.poll() != 0: +kvm_log.debug(Timeout elapsed or process terminated; output so far: \ ++ format_str_for_message(data.strip())) + return (match, data) def get_last_word(self, str): @@ -325,8 +331,11 @@ class kvm_spawn: Return a tuple (status, output) where status is the exit status or None if no exit status is available (e.g. timeout elapsed), and output is the - output of command. +output of command. +# Print some debugging info +kvm_log.debug(Sending command: %s % command) + # Read everything that's waiting to be read self.read_nonblocking(0.1) @@ -344,6 +353,11 @@ class kvm_spawn: return (None, output) status = int(\n.join(status.splitlines()[1:-1]).strip()) +# Print some debugging info +if status != 0: +kvm_log.debug(Command failed; status: %d, output: % status \ ++ format_str_for_message(output.strip())) + return (status, output) def get_command_status(self, command, timeout=30.0, internal_timeout=1.0, print_func=None): @@ -356,7 +370,7 @@ class kvm_spawn: (should take a string parameter) Return the exit status or None if no exit status is available (e.g. - timeout elapsed). +timeout elapsed). (status, output) = self.get_command_status_output(command, timeout, internal_timeout, print_func) return status @@ -688,6 +702,21 @@ def generate_random_string(length): return str +def format_str_for_message(str): +Format str so that it can be appended to a message. + +If str consists of one line, prefix it with a space. +If str consists of multiple lines, prefix it with a newline. + +num_lines = len(str.splitlines()) +if num_lines == 0: +return +elif num_lines == 1: +return + str +else: +return \n + str + + def wait_for(func, timeout, first=0.0, step=1.0, text=None): Wait until func() evaluates to True. diff --git a/client/tests/kvm_runtest_2/kvm_vm.py b/client/tests/kvm_runtest_2/kvm_vm.py index b3c46b6..0680f52 100644 --- a/client/tests/kvm_runtest_2/kvm_vm.py +++ b/client/tests/kvm_runtest_2/kvm_vm.py @@ -372,7 +372,8 @@ class VM: status, data = read_up_to_qemu_prompt(s, timeout) if not status: s.close() -kvm_log.debug(Could not find (qemu) prompt) +kvm_log.debug(Could not find (qemu) prompt; output so far: \ ++ kvm_utils.format_str_for_message(data)) return (1, ) # Send command s.sendall(command + \n) @@ -383,7 +384,8 @@ class VM: data = \n.join(data.splitlines()[1:]) if not status: s.close() -kvm_log.debug(Could not find (qemu) prompt after command) +kvm_log.debug(Could not find (qemu) prompt after command; output so far: \ ++ kvm_utils.format_str_for_message(data)) return (1, data) s.close() return (0, data) -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[KVM-AUTOTEST][PATCH] kvm_tests.cfg.sample: do not run bonnie and dbench on openSUSE-11 (no gcc).
From: Alexey Eromenko aerom...@redhat.com Signed-off-by: Alexey Eromenko aerom...@redhat.com Signed-off-by: Michael Goldish mgold...@redhat.com Signed-off-by: Uri Lublin u...@redhat.com diff --git a/client/tests/kvm_runtest_2/kvm_tests.cfg.sample b/client/tests/kvm_runtest_2/kvm_tests.cfg.sample index a38669d..c882ed5 100644 --- a/client/tests/kvm_runtest_2/kvm_tests.cfg.sample +++ b/client/tests/kvm_runtest_2/kvm_tests.cfg.sample @@ -160,7 +160,7 @@ variants: cdrom = linux/mandriva-one-2007-i386.iso - openSUSE-11: -no setup +no setup dbench bonnie image_name = openSUSE-11 install: steps = openSUSE-11.0-32.steps -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[KVM-AUTOTEST][PATCH] kvm_tests.cfg: make migration 2 (dst-src) depend on migration 1 (src-dst)
From: Uri Lublin u...@redhat.com If the first migration failed, skip the second migration. Signed-off-by: Uri Lublin u...@redhat.com diff --git a/client/tests/kvm_runtest_2/kvm_tests.cfg.sample b/client/tests/kvm_runtest_2/kvm_tests.cfg.sample index b0b75b2..8227b5f 100644 --- a/client/tests/kvm_runtest_2/kvm_tests.cfg.sample +++ b/client/tests/kvm_runtest_2/kvm_tests.cfg.sample @@ -61,7 +61,7 @@ variants: start_vm_for_migration_dst = yes migration_src = vm1 migration_dst = dst -- 2: +- 2: 1 start_vm_for_migration_vm1 = yes migration_src = dst migration_dst = vm1 -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[KVM-AUTOTEST][PATCH] kvm_tests.cfg.sample: do not run linux_s3 on DSL and RHEL-3.9.
From: Alexey Eromenko aerom...@redhat.com These guests apparently do not support S3. Signed-off-by: Alexey Eromenko aerom...@redhat.com Signed-off-by: Michael Goldish mgold...@redhat.com Signed-off-by: Uri Lublin u...@redhat.com diff --git a/client/tests/kvm_runtest_2/kvm_tests.cfg.sample b/client/tests/kvm_runtest_2/kvm_tests.cfg.sample index a3bf988..8aeaf22 100644 --- a/client/tests/kvm_runtest_2/kvm_tests.cfg.sample +++ b/client/tests/kvm_runtest_2/kvm_tests.cfg.sample @@ -145,7 +145,7 @@ variants: md5sum_1m = 9822ab5097e37e8fe306ef2192727db4 - DSL-4.2.5: -no setup dbench bonnie +no setup dbench bonnie linux_s3 image_name = dsl-4.2.5 install: steps = DSL-4.2.5.steps @@ -241,7 +241,7 @@ variants: md5sum_1m=58fa63eaee68e269f4cb1d2edf479792 - 3.9.i386: -no setup dbench bonnie +no setup dbench bonnie linux_s3 image_name = rhel3-32 install: steps=RHEL-3.9-i386.steps @@ -250,7 +250,7 @@ variants: md5sum_1m=5f10c9417c7b8372b3456c1b5f3f9ed0 - 3.9.x86_64: -no setup dbench bonnie +no setup dbench bonnie linux_s3 image_name = rhel3-64 install: steps=RHEL-3.9-x86_64.steps -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Luvalley-2 has been released: running KVM below any operating system
How about performance comparision with kvm guests? Xiantao -Original Message- From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf Of Xiaodong Yi Sent: Thursday, April 16, 2009 9:54 AM To: kvm@vger.kernel.org Subject: Luvalley-2 has been released: running KVM below any operating system Luvalley is a Virtual Machine Monitor (VMM) spawned from the KVM project. Its part of source codes are derived from KVM to virtualize CPU instructions and memory management unit (MMU). However, its overall architecture is completely different from KVM, but somewhat like Xen. Luvalley runs outside of Linux, just like Xen's architecture. Any operating system, including Linux, could be used as Luvalley's scheduler, memory manager, physical device driver provider and virtual IO device emulator. Currently, Luvalley supports Linux and Windows. That is to say, one may run Luvalley to boot a Linux or Windows, and then run multiple virtualized operating systems on such Linux or Windows. If you are interested in Luvalley project, you may download the source codes from http://sourceforge.net/projects/luvalley/ This release (i.e., luvalley-2) updated Qemu in both Linux and Windows. So the limitations of the previous release (i.e., luvalley-1) have been partially eliminated. For example, the Qemu in Windows allows to create disk images and install gueest operating systems. This release has 4 tarballs: * luvalley-2.tgz: this is the source codes of the kernel part of Luvalley, which should be compiled in Linux. It is running below any operating system to provide virtualization extension for Intel's X86/32 computers. See the README file of the tarball for how to compile and run Luvalley. * qemu-linux.tgz: this is the source codes of the modified Qemu for running virtualized guest OSs in Linux. It is derived from Qemu of KVM-83. See the README file of the tarball for how to compile and run. * qemu-windows.tgz: this is the source codes of the modified Qemu for running virtualized guest OSs in Windows. It is derived from Qemu-0.10.2. See the README file of the tarball for how to build and run. * WindowsXP-Bins.rar: this is the pre-compiled binaries for running in Windows XP. It should be uncompressed in Windows XP operating system with WinRAR or other programs that supports .rar format. See the README file of the package for how to install and run in Windows XP. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm with OpenBSD 4.5
kvm-84 has same error. How to disable oos optimization, is there a switch? 2009/4/16 Brian Jackson i...@theiggy.com: You might want to try 84 with oos optimization off (or better yet 85 when it comes out). There was a bug recently (post 84) fixed that affected some BSDs. On Wednesday 15 April 2009 22:51:13 Dongsheng Song wrote: Can any one run OpenBSD 4.5[1,2] under kvm ? I run OpenBSD 4.4 under Debian 5.0 amd64(linux 2.6.26 with kvm-72) fine, and snapshots older than 2009-04. The new snapshots can install smoothly, but stopped at display 'setting tty flags'. [1] ftp://ftp.openbsd.org/pub/OpenBSD/snapshots/i386/ [2] ftp://ftp.openbsd.org/pub/OpenBSD/snapshots/amd64/ -- Dongsheng Song -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM: x86: use kvm_set_cr3/cr4 in ioctl_set_sregs
Marcelo Tosatti wrote: Matt T. Yourst notes that kvm_arch_vcpu_ioctl_set_sregs lacks validity checking for the new cr3 value: Userspace callers of KVM_SET_SREGS can pass a bogus value of cr3 to the kernel. This will trigger a NULL pointer access in gfn_to_rmap() when userspace next tries to call KVM_RUN on the affected VCPU and kvm attempts to activate the new non-existent page table root. This happens since kvm only validates that cr3 points to a valid guest physical memory page when code *inside* the guest sets cr3. However, kvm currently trusts the userspace caller (e.g. QEMU) on the host machine to always supply a valid page table root, rather than properly validating it along with the rest of the reloaded guest state. http://sourceforge.net/tracker/?func=detailatid=893831aid=2687641group_id=180599 Follow Avi's suggestion to use kvm_set_cr3, and do the same for assigment of cr4. Note kvm_set_cr4 unconditionally resets the mmu context, as long as cr4 is valid. Signed-off-by: Marcelo Tosatti mtosa...@redhat.com diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 148cde2..89fb3c7 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -3985,25 +3985,19 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu, kvm_x86_ops-set_gdt(vcpu, dt); vcpu-arch.cr2 = sregs-cr2; - mmu_reset_needed |= vcpu-arch.cr3 != sregs-cr3; - vcpu-arch.cr3 = sregs-cr3; + kvm_set_cr3(vcpu, sregs-cr3); kvm_set_cr8(vcpu, sregs-cr8); mmu_reset_needed |= vcpu-arch.shadow_efer != sregs-efer; kvm_x86_ops-set_efer(vcpu, sregs-efer); kvm_set_apic_base(vcpu, sregs-apic_base); - kvm_x86_ops-decache_cr4_guest_bits(vcpu); - mmu_reset_needed |= vcpu-arch.cr0 != sregs-cr0; kvm_x86_ops-set_cr0(vcpu, sregs-cr0); vcpu-arch.cr0 = sregs-cr0; - mmu_reset_needed |= vcpu-arch.cr4 != sregs-cr4; - kvm_x86_ops-set_cr4(vcpu, sregs-cr4); - if (!is_long_mode(vcpu) is_pae(vcpu)) - load_pdptrs(vcpu, vcpu-arch.cr3); + kvm_set_cr4(vcpu, sregs-cr4); if (mmu_reset_needed) kvm_mmu_reset_context(vcpu); Consider the following: current state: cr3 = 0 cr4.pae = 0 new state: cr3 = 0x800 cr4.pae = 1 When you call kvm_set_cr3(), it will inject a #GP into the guest because we are setting bit 11 when cr4.pae=0, which is illegal. However the new cr4.pae=1, so the new state was in fact legal! There are a few ways out, one is to first go back to real mode and set eveything up carefully in the right order (including EFER.LMA and EFER.LME, and CS.L). The other is to refactor kvm_set_* so that we have internal setters which won't trigger these faults (but do need to check at the end that the state is legal). This first method is probably better since that's what the guest does when booting anyway. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM: x86: use kvm_set_cr3/cr4 in ioctl_set_sregs
On Thu, Apr 16, 2009 at 11:56:15AM +0300, Avi Kivity wrote: Marcelo Tosatti wrote: Matt T. Yourst notes that kvm_arch_vcpu_ioctl_set_sregs lacks validity checking for the new cr3 value: Userspace callers of KVM_SET_SREGS can pass a bogus value of cr3 to the kernel. This will trigger a NULL pointer access in gfn_to_rmap() when userspace next tries to call KVM_RUN on the affected VCPU and kvm attempts to activate the new non-existent page table root. This happens since kvm only validates that cr3 points to a valid guest physical memory page when code *inside* the guest sets cr3. However, kvm currently trusts the userspace caller (e.g. QEMU) on the host machine to always supply a valid page table root, rather than properly validating it along with the rest of the reloaded guest state. http://sourceforge.net/tracker/?func=detailatid=893831aid=2687641group_id=180599 Follow Avi's suggestion to use kvm_set_cr3, and do the same for assigment of cr4. Note kvm_set_cr4 unconditionally resets the mmu context, as long as cr4 is valid. Signed-off-by: Marcelo Tosatti mtosa...@redhat.com diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 148cde2..89fb3c7 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -3985,25 +3985,19 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu, kvm_x86_ops-set_gdt(vcpu, dt); vcpu-arch.cr2 = sregs-cr2; -mmu_reset_needed |= vcpu-arch.cr3 != sregs-cr3; -vcpu-arch.cr3 = sregs-cr3; + kvm_set_cr3(vcpu, sregs-cr3); kvm_set_cr8(vcpu, sregs-cr8); mmu_reset_needed |= vcpu-arch.shadow_efer != sregs-efer; kvm_x86_ops-set_efer(vcpu, sregs-efer); kvm_set_apic_base(vcpu, sregs-apic_base); - kvm_x86_ops-decache_cr4_guest_bits(vcpu); - mmu_reset_needed |= vcpu-arch.cr0 != sregs-cr0; kvm_x86_ops-set_cr0(vcpu, sregs-cr0); vcpu-arch.cr0 = sregs-cr0; - mmu_reset_needed |= vcpu-arch.cr4 != sregs-cr4; -kvm_x86_ops-set_cr4(vcpu, sregs-cr4); -if (!is_long_mode(vcpu) is_pae(vcpu)) -load_pdptrs(vcpu, vcpu-arch.cr3); +kvm_set_cr4(vcpu, sregs-cr4); if (mmu_reset_needed) kvm_mmu_reset_context(vcpu); Consider the following: current state: cr3 = 0 cr4.pae = 0 new state: cr3 = 0x800 cr4.pae = 1 When you call kvm_set_cr3(), it will inject a #GP into the guest because we are setting bit 11 when cr4.pae=0, which is illegal. However the new cr4.pae=1, so the new state was in fact legal! There are a few ways out, one is to first go back to real mode and set eveything up carefully in the right order (including EFER.LMA and EFER.LME, and CS.L). The other is to refactor kvm_set_* so that we have internal setters which won't trigger these faults (but do need to check at the end that the state is legal). This first method is probably better since that's what the guest does when booting anyway. Humpf. And something like this? Or GP# instead of triple fault? diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 148cde2..3e63bac 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -3986,7 +3986,10 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu, vcpu-arch.cr2 = sregs-cr2; mmu_reset_needed |= vcpu-arch.cr3 != sregs-cr3; - vcpu-arch.cr3 = sregs-cr3; + if (gfn_to_memslot(vcpu-kvm, sregs-cr3 PAGE_SHIFT)) + vcpu-arch.cr3 = sregs-cr3; + else + set_bit(KVM_REQ_TRIPLE_FAULT, vcpu-requests); kvm_set_cr8(vcpu, sregs-cr8); -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] KVM: ia64: Flush all TLBs once guest's memory mapping changes.
From dcb73b5db2e91213a2536542945645caaf23bfe3 Mon Sep 17 00:00:00 2001
From: Xiantao Zhang xiantao.zh...@intel.com
Date: Thu, 16 Apr 2009 17:59:16 +0800
Subject: [PATCH] KVM: ia64: Flush all TLBs once guest's memory mapping changes.
Flush all vcpu's TLB entries once changes guest's memory mapping.
Signed-off-by: Xiantao Zhang xiantao.zh...@intel.com
---
arch/ia64/kvm/kvm-ia64.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/ia64/kvm/kvm-ia64.c b/arch/ia64/kvm/kvm-ia64.c
index 112b402..2a88e42 100644
--- a/arch/ia64/kvm/kvm-ia64.c
+++ b/arch/ia64/kvm/kvm-ia64.c
@@ -1629,6 +1629,7 @@ int kvm_arch_set_memory_region(struct kvm *kvm,
void kvm_arch_flush_shadow(struct kvm *kvm)
{
+ kvm_flush_remote_tlbs(kvm);
}
long kvm_arch_dev_ioctl(struct file *filp,
--
1.6.0
0001-KVM-ia64-Flush-all-TLBs-once-guest-s-memory-mappin.patch
Description: 0001-KVM-ia64-Flush-all-TLBs-once-guest-s-memory-mappin.patch
Re: [PATCH] deal with interrupt shadow state for emulated instruction
H. Peter Anvin wrote: Avi Kivity wrote: Why do we care? The guest can only harm itself, and if it wants to disable interrupts, it would be a lot easier for it to run a plain 'cli'. I guess it would be a problem if we emulated 'mov ss' for ordinary userspace or vm86 mode, but we don't. Well, the answer is that mov ss is an unprivileged instruction. We don't emulate guest user mode. Well, if guest userspace can convince its kernel to give it access to some memory mapped I/O register, I guess it can execute repeated 'mov ss, mmio' and starve the guest kernel. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM: x86: use kvm_set_cr3/cr4 in ioctl_set_sregs
Marcelo Tosatti wrote: Humpf. And something like this? Or GP# instead of triple fault? diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 148cde2..3e63bac 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -3986,7 +3986,10 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu, vcpu-arch.cr2 = sregs-cr2; mmu_reset_needed |= vcpu-arch.cr3 != sregs-cr3; - vcpu-arch.cr3 = sregs-cr3; + if (gfn_to_memslot(vcpu-kvm, sregs-cr3 PAGE_SHIFT)) + vcpu-arch.cr3 = sregs-cr3; + else + set_bit(KVM_REQ_TRIPLE_FAULT, vcpu-requests); kvm_set_cr8(vcpu, sregs-cr8); Well, that plugs the hole. Triple fault is better than #GP IMO. We're still missing checks on reserved bits, etc., but that can come later. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
KVM: x86: check for cr3 validity in ioctl_set_sregs
Matt T. Yourst notes that kvm_arch_vcpu_ioctl_set_sregs lacks validity checking for the new cr3 value: Userspace callers of KVM_SET_SREGS can pass a bogus value of cr3 to the kernel. This will trigger a NULL pointer access in gfn_to_rmap() when userspace next tries to call KVM_RUN on the affected VCPU and kvm attempts to activate the new non-existent page table root. This happens since kvm only validates that cr3 points to a valid guest physical memory page when code *inside* the guest sets cr3. However, kvm currently trusts the userspace caller (e.g. QEMU) on the host machine to always supply a valid page table root, rather than properly validating it along with the rest of the reloaded guest state. http://sourceforge.net/tracker/?func=detailatid=893831aid=2687641group_id=180599 Check for a valid cr3 address in kvm_arch_vcpu_ioctl_set_sregs, triple fault in case of failure. Signed-off-by: Marcelo Tosatti mtosa...@redhat.com Index: kvm/arch/x86/kvm/x86.c === --- kvm.orig/arch/x86/kvm/x86.c +++ kvm/arch/x86/kvm/x86.c @@ -3986,7 +3986,13 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct vcpu-arch.cr2 = sregs-cr2; mmu_reset_needed |= vcpu-arch.cr3 != sregs-cr3; - vcpu-arch.cr3 = sregs-cr3; + + down_read(vcpu-kvm-slots_lock); + if (gfn_to_memslot(vcpu-kvm, sregs-cr3 PAGE_SHIFT)) + vcpu-arch.cr3 = sregs-cr3; + else + set_bit(KVM_REQ_TRIPLE_FAULT, vcpu-requests); + up_read(vcpu-kvm-slots_lock); kvm_set_cr8(vcpu, sregs-cr8); -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] add ksm kernel shared memory driver.
On Wed, Apr 15, 2009 at 05:43:03PM -0700, Jeremy Fitzhardinge wrote: Shouldn't that be kmap_atomic's job anyway? Otherwise it would be hard to No because those are full noops in no-highmem kernels. I commented in other email why I think it's safe thanks to the wrprotect + smp tlb flush of the userland PTE. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM: x86: check for cr3 validity in ioctl_set_sregs
Marcelo Tosatti wrote: Matt T. Yourst notes that kvm_arch_vcpu_ioctl_set_sregs lacks validity checking for the new cr3 value: Userspace callers of KVM_SET_SREGS can pass a bogus value of cr3 to the kernel. This will trigger a NULL pointer access in gfn_to_rmap() when userspace next tries to call KVM_RUN on the affected VCPU and kvm attempts to activate the new non-existent page table root. This happens since kvm only validates that cr3 points to a valid guest physical memory page when code *inside* the guest sets cr3. However, kvm currently trusts the userspace caller (e.g. QEMU) on the host machine to always supply a valid page table root, rather than properly validating it along with the rest of the reloaded guest state. http://sourceforge.net/tracker/?func=detailatid=893831aid=2687641group_id=180599 Check for a valid cr3 address in kvm_arch_vcpu_ioctl_set_sregs, triple fault in case of failure. Signed-off-by: Marcelo Tosatti mtosa...@redhat.com Index: kvm/arch/x86/kvm/x86.c === --- kvm.orig/arch/x86/kvm/x86.c +++ kvm/arch/x86/kvm/x86.c @@ -3986,7 +3986,13 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct vcpu-arch.cr2 = sregs-cr2; mmu_reset_needed |= vcpu-arch.cr3 != sregs-cr3; - vcpu-arch.cr3 = sregs-cr3; + + down_read(vcpu-kvm-slots_lock); + if (gfn_to_memslot(vcpu-kvm, sregs-cr3 PAGE_SHIFT)) + vcpu-arch.cr3 = sregs-cr3; + else + set_bit(KVM_REQ_TRIPLE_FAULT, vcpu-requests); + up_read(vcpu-kvm-slots_lock); kvm_set_cr8(vcpu, sregs-cr8); Isn't this self-defeating? If you drop slots_lock, cr3 may be invalid again by the time you set cvpu-arch.cr3? -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM: x86: check for cr3 validity in ioctl_set_sregs
Avi Kivity wrote: Marcelo Tosatti wrote: Matt T. Yourst notes that kvm_arch_vcpu_ioctl_set_sregs lacks validity checking for the new cr3 value: Userspace callers of KVM_SET_SREGS can pass a bogus value of cr3 to the kernel. This will trigger a NULL pointer access in gfn_to_rmap() when userspace next tries to call KVM_RUN on the affected VCPU and kvm attempts to activate the new non-existent page table root. This happens since kvm only validates that cr3 points to a valid guest physical memory page when code *inside* the guest sets cr3. However, kvm currently trusts the userspace caller (e.g. QEMU) on the host machine to always supply a valid page table root, rather than properly validating it along with the rest of the reloaded guest state. http://sourceforge.net/tracker/?func=detailatid=893831aid=2687641group_id=180599 Check for a valid cr3 address in kvm_arch_vcpu_ioctl_set_sregs, triple fault in case of failure. Signed-off-by: Marcelo Tosatti mtosa...@redhat.com Index: kvm/arch/x86/kvm/x86.c === --- kvm.orig/arch/x86/kvm/x86.c +++ kvm/arch/x86/kvm/x86.c @@ -3986,7 +3986,13 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct vcpu-arch.cr2 = sregs-cr2; mmu_reset_needed |= vcpu-arch.cr3 != sregs-cr3; -vcpu-arch.cr3 = sregs-cr3; + +down_read(vcpu-kvm-slots_lock); +if (gfn_to_memslot(vcpu-kvm, sregs-cr3 PAGE_SHIFT)) +vcpu-arch.cr3 = sregs-cr3; +else +set_bit(KVM_REQ_TRIPLE_FAULT, vcpu-requests); +up_read(vcpu-kvm-slots_lock); kvm_set_cr8(vcpu, sregs-cr8); Isn't this self-defeating? If you drop slots_lock, cr3 may be invalid again by the time you set cvpu-arch.cr3? Uh, sorry, of course not. I misread down as up. Bad day for me. Will apply the patch. Still, don't we have a problem if userspace drops the memory slot where cr3 points to? -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Make BIOS irq0-inti2 override configurable from userspace
Beth Kon wrote: These patches resolve the irq0-inti2 override issue, and get the hpet working on kvm with and without -no-kvm-irqchip (i.e., when hpet takes over, it disables userspace or in-kernel pit as appropriate). The irq0-inti2 override will always be used unless the kernel cannot do irq routing (i.e., compatibility with old kernels). So if the kernel is capable, userspace sets up irq0-inti2 via the irq routing interface, and adds the irq0-inti2 override to the MADT interrupt source override table, and the mp table (for the no-acpi case). A couple of months ago, Marcelo was seeing RHEL5 guests complain of invalid checksum with these patches, but later he couldn't reproduce it, and I'm not seeing it now. While all guests still need to be fully tested, everything appears to be in order. I've tested on win2k864, win2k832, RHEL5.3 32 bit, and ubuntu 8.10 64 bit. Both patches look good. However, the bios in kvm-userspace.git is pretty old. To ease later merging, I'd like to update the bios first, so please rebase the patches once I've done that. It will take a few days since large merges are blocked while I struggle to get a working kvm-85 out. Please also separate the bios patches from qemu patches. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2768533 ] SCSI: VM unable to reboot from SCSI controller
Bugs item #2768533, was opened at 2009-04-16 16:01 Message generated for change (Tracker Item Submitted) made by technologov You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2768533group_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: SCSI: VM unable to reboot from SCSI controller Initial Comment: All Red Hat-based systems (RHEL, Fedora) have failed during automated tests on SCSI disks on KVM. It turned out to be a problem of Qemu/KVM, where after a software reboot (i.e. initiated by guest OS), the system is unable to boot from SCSI controller. To reboot successfully you need either soft reboot+IDE or Hard reboot (Qemu cold boot)+SCSI. The Command sent to Qemu/KVM: /usr/local/bin/qemu-system-x86_64 -m 512 -monitor tcp:localhost:4602,server,nowait -cdrom /isos/linux/Fedora-8-i386-DVD.iso -drive file=/vm/fedora8-32.qcow2,if=scsi,boot=on -name fedora8-32 Host: RHEL 5/x64, KVM-85rc6. (tried both Intel and AMD) Guest: RHEL 5, Fedora 8, Fedora 9 (tried both 32 and 64-bit). -Alexey, 16.4.2009. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2768533group_id=180599 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: ia64: Flush all TLBs once guest's memory mapping changes.
Zhang, Xiantao wrote: From dcb73b5db2e91213a2536542945645caaf23bfe3 Mon Sep 17 00:00:00 2001 From: Xiantao Zhang xiantao.zh...@intel.com Date: Thu, 16 Apr 2009 17:59:16 +0800 Subject: [PATCH] KVM: ia64: Flush all TLBs once guest's memory mapping changes. Flush all vcpu's TLB entries once changes guest's memory mapping. Applied, thanks. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
hanging while install OpenSolaris (Nov 2008 version)
I got a mid-way hang while installing OpenSolaris on KVM guest yesterday. The hardware is kvm-intel enabled. I tried the same thing on Athlon64, but it does not have svm hardware enabled. So qemu startup saying /dev/kvm cannot be found, even though i had explicitly insmod kvm, and dmesg show svm not enabled message. But it is able to go through the installation. How can i debug via kvmtrace (or systemtap) to find out at which point it hanged? I gdb attached the hanging process (from host OS side), but got a stuck at some select() in vl.cnot helpful. Best will be a debugging backtrace at the guest level, but then the guest is still midway reading the iso images, and then hang there.no installation done yet. Thank you for the advice. -- Regards, Peter Teoh -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
AW: AW: AW: AW: AW: KVM performance
Hello, I've compiled a new kernel v2.6.27-rc5 with the modified svm.c. But the behaviour of the vlc process in the guest is still the same. I've exported additional cpu features to the guest, e.g. mmxext with kvm-84. But no performance changes. I was not able to export the cpu flags 3dnow and 3dnowext to the guest, no error but they are not visible in /proc/cpuinfo. Not sure why. Regards Stefanie BRAUN, Stefanie wrote: qemu-kvm -cpu ? only shows qemu64, qemu32, 486, pentium, pentium2, pentium3, athlon It can also take additional +feature or -feature parameters. Oh, maybe kvm-84 doesn't have this support? try http://userweb.kernel.org/~avi/kvm-85rc6/. -Ursprüngliche Nachricht- Von: Avi Kivity [mailto:a...@redhat.com] Gesendet: Dienstag, 14. April 2009 10:48 An: BRAUN, Stefanie Cc: kvm@vger.kernel.org Betreff: Re: AW: AW: AW: AW: KVM performance BRAUN, Stefanie wrote: Hello, the host runs on a Dual-Core AMD Opteron Processor. Does there exist a similar AMD parameter? You can add individual host cpu features by using '-cpu qemu64,+feature', where feature is taken from the host /proc/cpuinfo. Do you know which cpu features the program can take advantage of? Also please try replacing the constant 0x0007040600070406ULL in kernel/x86/svm.c with 0x0606060606060606ULL and see what happens (don't forget to reload the modules). -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm with OpenBSD 4.5
it's a module option to the kvm option. parm: oos_shadow:bool On Thursday 16 April 2009 03:43:56 Dongsheng Song wrote: kvm-84 has same error. How to disable oos optimization, is there a switch? 2009/4/16 Brian Jackson i...@theiggy.com: You might want to try 84 with oos optimization off (or better yet 85 when it comes out). There was a bug recently (post 84) fixed that affected some BSDs. On Wednesday 15 April 2009 22:51:13 Dongsheng Song wrote: Can any one run OpenBSD 4.5[1,2] under kvm ? I run OpenBSD 4.4 under Debian 5.0 amd64(linux 2.6.26 with kvm-72) fine, and snapshots older than 2009-04. The new snapshots can install smoothly, but stopped at display 'setting tty flags'. [1] ftp://ftp.openbsd.org/pub/OpenBSD/snapshots/i386/ [2] ftp://ftp.openbsd.org/pub/OpenBSD/snapshots/amd64/ -- Dongsheng Song -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2768533 ] SCSI/VirtIO: VM unable to reboot from non-IDE controller
Bugs item #2768533, was opened at 2009-04-16 16:01 Message generated for change (Settings changed) made by technologov You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2768533group_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: 7 Private: No Submitted By: Technologov (technologov) Assigned to: Nobody/Anonymous (nobody) Summary: SCSI/VirtIO: VM unable to reboot from non-IDE controller Initial Comment: All Red Hat-based systems (RHEL, Fedora) have failed during automated tests on SCSI disks on KVM. It turned out to be a problem of Qemu/KVM, where after a software reboot (i.e. initiated by guest OS), the system is unable to boot from SCSI controller. To reboot successfully you need either soft reboot+IDE or Hard reboot (Qemu cold boot)+SCSI. The Command sent to Qemu/KVM: /usr/local/bin/qemu-system-x86_64 -m 512 -monitor tcp:localhost:4602,server,nowait -cdrom /isos/linux/Fedora-8-i386-DVD.iso -drive file=/vm/fedora8-32.qcow2,if=scsi,boot=on -name fedora8-32 Host: RHEL 5/x64, KVM-85rc6. (tried both Intel and AMD) Guest: RHEL 5, Fedora 8, Fedora 9 (tried both 32 and 64-bit). -Alexey, 16.4.2009. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2768533group_id=180599 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2768533 ] SCSI/VirtIO: VM unable to reboot from non-IDE controller
Bugs item #2768533, was opened at 2009-04-16 16:01 Message generated for change (Comment added) made by technologov You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2768533group_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: 7 Private: No Submitted By: Technologov (technologov) Assigned to: Nobody/Anonymous (nobody) Summary: SCSI/VirtIO: VM unable to reboot from non-IDE controller Initial Comment: All Red Hat-based systems (RHEL, Fedora) have failed during automated tests on SCSI disks on KVM. It turned out to be a problem of Qemu/KVM, where after a software reboot (i.e. initiated by guest OS), the system is unable to boot from SCSI controller. To reboot successfully you need either soft reboot+IDE or Hard reboot (Qemu cold boot)+SCSI. The Command sent to Qemu/KVM: /usr/local/bin/qemu-system-x86_64 -m 512 -monitor tcp:localhost:4602,server,nowait -cdrom /isos/linux/Fedora-8-i386-DVD.iso -drive file=/vm/fedora8-32.qcow2,if=scsi,boot=on -name fedora8-32 Host: RHEL 5/x64, KVM-85rc6. (tried both Intel and AMD) Guest: RHEL 5, Fedora 8, Fedora 9 (tried both 32 and 64-bit). -Alexey, 16.4.2009. -- Comment By: Technologov (technologov) Date: 2009-04-16 17:12 Message: This problem also exists for VirtIO block device. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2768533group_id=180599 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Getting VT-d passthru to work
Hi List, I'm a newbie at kvm/linux so hopefully I'm not asking anything too obvious. Can anyone please recommend the best bits to use for getting VT-d passthru to work? I've tried kvm-84 with Fedora 10, but the kernel is 2.6.27.5. I'm trying the Fedora 11 Beta but I've hit other issues. My system is a Dell T7400 Xeon quad-core. Any all input is gratefully appreciated. Ed Nadolski LSI -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AW: AW: AW: AW: AW: KVM performance
BRAUN, Stefanie wrote: Hello, I've compiled a new kernel v2.6.27-rc5 with the modified svm.c. But the behaviour of the vlc process in the guest is still the same. I've exported additional cpu features to the guest, e.g. mmxext with kvm-84. But no performance changes. I was not able to export the cpu flags 3dnow and 3dnowext to the guest, no error but they are not visible in /proc/cpuinfo. Not sure why. Can you test on an intel host (relative performance host vs guest)? -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm with OpenBSD 4.5
On Thu, Apr 16, 2009 at 4:59 AM, Theo de Raadt dera...@cvs.openbsd.org wrote: If they claim to provide a proper i386/amd64 vm environment, and we don't run properly ... Look, considering we run very well on 99% of PCs, it means they their claims are balony. I concur, I had problems with VMware (don't cut my head off :) a couple of years ago where it would not compile a release properly whereas when I switched to Xen, it all worked out without a hitch. Cheers, Steph -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] add ksm kernel shared memory driver.
Andrea Arcangeli wrote: On Wed, Apr 15, 2009 at 05:43:03PM -0700, Jeremy Fitzhardinge wrote: Shouldn't that be kmap_atomic's job anyway? Otherwise it would be hard to No because those are full noops in no-highmem kernels. I commented in other email why I think it's safe thanks to the wrprotect + smp tlb flush of the userland PTE. I think Andrew's query was about data cache synchronization in architectures with virtually indexed d-cache. On x86 it's a non-issue, but on architectures for which it is an issue, I assume kmap_atomic does any necessary cache flushes, as it does tlb flushes on x86 (which may be none at all, if no mapping actually happens). J -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] ksm - dynamic page sharing driver for linux v3
On Wednesday 15 April 2009 08:09:03 Andrew Morton wrote: On Thu, 9 Apr 2009 06:58:37 +0300 Izik Eidus iei...@redhat.com wrote: KSM is a linux driver that allows dynamicly sharing identical memory pages between one or more processes. Generally looks OK to me. But that doesn't mean much. We should rub bottles with words like hugh and nick on them to be sure. I haven't looked too closely at it yet sorry. Hugh has a great eye for these details, though, hint hint :) As everyone knows, my favourite thing is to say nasty things about any new feature that adds complexity to common code. I feel like crying to hear about how many more instances of MS Office we can all run, if only we apply this patch. And the poorly written HPC app just sounds like scrapings from the bottom of justification barrel. I'm sorry, maybe I'm way off with my understanding of how important this is. There isn't too much help in the changelog. A discussion of where the memory savings comes from, and how far does things like sharing of fs image, or ballooning goes and how much extra savings we get from this... with people from other hypervisors involved as well. Have I missed this kind of discussion? Careful what you wish for, ay? :) -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] ksm - dynamic page sharing driver for linux v3
Nick Piggin wrote: On Wednesday 15 April 2009 08:09:03 Andrew Morton wrote: On Thu, 9 Apr 2009 06:58:37 +0300 Izik Eidus iei...@redhat.com wrote: KSM is a linux driver that allows dynamicly sharing identical memory pages between one or more processes. Generally looks OK to me. But that doesn't mean much. We should rub bottles with words like hugh and nick on them to be sure. I haven't looked too closely at it yet sorry. Hugh has a great eye for these details, though, hint hint :) As everyone knows, my favourite thing is to say nasty things about any new feature that adds complexity to common code. The whole idea and the way i wrote it so it wont touch common code, i didnt change the linux mm logic no where. The worst thing that we have add is helper functions. I feel like crying to hear about how many more instances of MS Office we can all run, if only we apply this patch. And more instances of linux guests... And the poorly written HPC app just sounds like scrapings from the bottom of justification barrel. So if you have a big rendering application that load gigas of geometrical data that is handled by many threads and you have a case that each thread sometimes change this geometrical data and you dont want the other threads will notice it. How would you share it in traditional way?, after one time shared data will get cowed, how will you recollect it again when it become identical? KSM do it for applications transparently KSM writing motivation indeed was KVM where there it is highly needed you may check what VMware say about the fact that they have much better overcommit than Hyper-V / XEN: http://blogs.vmware.com/virtualreality/2008/03/cheap-hyperviso.html It is important to understand that in virtualization enviorments there are cases where memory is much more critical than any other resource for higher density. Together with KSM, KVM will have the same memory overcommit abilitys such as VMware have. I'm sorry, maybe I'm way off with my understanding of how important this is. There isn't too much help in the changelog. A discussion of where the memory savings comes from, Memory saving come from identical librarys, identical kernels, zeroed pages - that is for virtualization. The Librarys code will always be identical among similar guests, so why have this code at multiple places on the host memory? and how far does things like sharing of fs image, or ballooning goes and how much extra savings we get from this... Ballooning is much worse when it come to performance, beacuse what it does is shrink the guest memory, with KSM we find identical pages and merge them into one page, so we dont get guest performance lose with people from other hypervisors involved as well. Have I missed this kind of discussion? Careful what you wish for, ay? :) -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: hanging while install OpenSolaris (Nov 2008 version)
On Thu, Apr 16, 2009 at 09:11:03AM -0400, Peter Teoh wrote: I got a mid-way hang while installing OpenSolaris on KVM guest yesterday. The hardware is kvm-intel enabled. I tried the same thing on Athlon64, but it does not have svm hardware enabled. So qemu startup saying /dev/kvm cannot be found, even though i had explicitly insmod kvm, and dmesg show svm not enabled message. But it is able to go through the installation. How can i debug via kvmtrace (or systemtap) to find out at which point it hanged? I gdb attached the hanging process (from host OS side), but got a stuck at some select() in vl.cnot helpful. Best will be a debugging backtrace at the guest level, but then the guest is still midway reading the iso images, and then hang there.no installation done yet. Thank you for the advice. Peter, Take a look at http://www.linux-kvm.org/page/Bugs, there's some information that might be helpful there. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tlb flushing after spin_unlock of mmu lock
Peter,
On Sat, Apr 11, 2009 at 12:45:21AM -0400, Peter Teoh wrote:
In this function, the TLB flushing comes before spin unlock,
void kvm_mmu_slot_remove_write_access(struct kvm *kvm, int slot)
{
struct kvm_mmu_page *sp;
spin_lock(kvm-mmu_lock);
kvm_flush_remote_tlbs(kvm);
spin_unlock(kvm-mmu_lock);
}
kvm_vm_ioctl_get_dirty_log does:
down_write(slots_lock)
- collect data from dirty bitmap (kvm_get_dirty_log)
if (something was dirty)
- remove write access for all translations
- flush remote tlb's
- clear the dirty bitmap
up_write(slots_lock)
The vmexit path (take a look at vcpu_run), takes slots_lock in
read-mode. This means that no other vcpu will be able to dirty a
shadow translation (spte) in the meantime.
So its safe.
but in kvm_vm_ioctl_set_memory_alias():
spin_unlock(kvm-mmu_lock);
kvm_mmu_zap_all(kvm);
it comes after inside kvm_mmu_zap_all(). Does it sound logical?
Note that here it also takes slots_lock in write-mode, which blocks all
other vcpus.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: hanging while install OpenSolaris (Nov 2008 version)
Peter Teoh htmldevelo...@gmail.com writes:
I got a mid-way hang while installing OpenSolaris on KVM guest yesterday.
[...]
How can i debug via kvmtrace (or systemtap) to find out at which point it
hanged? [...]
In recent kernels, kvm tracing is done by markers, which systemtap can
attach to. Their use of markers is not terribly sophisticated, so all
the different events get collapsed down to just two. You can easily
log them:
stap -e 'probe kernel.mark(kvm_trace*) {
printf(%s %u %p %u %u %u %u %u %u\n,
$name, $arg1, $arg2, $arg3, $arg4, $arg5, $arg6, $arg7, $arg8)
}'
Decoding them further could be done with another tool, or systemtap script
that parses $arg1... etc. further.
Best will be a debugging backtrace at the guest level, but then the
guest is still midway reading the iso images [...]
We don't have a way of doing that (inspecting the internals of a VM
from the host) and we haven't thought about it much yet.
- FChE
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Split kvm source tarballs
Any idea when the split will happen? -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] deal with interrupt shadow state for emulated instruction
Avi Kivity wrote: We don't emulate guest user mode. Well, if guest userspace can convince its kernel to give it access to some memory mapped I/O register, I guess it can execute repeated 'mov ss, mmio' and starve the guest kernel. It doesn't need a MMIO register to do that, even. -hpa -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -tip 3/6 V4.1] x86: instruction decorder API
H. Peter Anvin wrote:
Jim Keniston wrote:
For user-space probing, we've been concentrating on native-built
executables. Am I correct in thinking that we'll see 16-bit or V86 mode
only on legacy apps built elsewhere? In any case, it only makes sense
to build on the kvm folks' work in this regard.
That's a fair assumption; you will of course need to test it and take
appropriate action if it doesn't pan out.
As noted, the INAT tables follow the kvm model of one fat bitmap of
attributes per opcode, rather than the kprobes/uprobes model of one or
two 256-bit tables per attribute. (This latter approach was due to the
gradual accumulation of tables over the years.)
I like the bitmap-per-opcode approach because it's relatively easy to
see in one place everything you're saying about a particular opcode.
But with all the potential clients for this service, it's not clear that
we'll get by with a single bitmap for every opcode. (x86 kvm uses 32
bits per opcode, I think, and the INAT tables use 10. Seems like we
could overrun 64 bits pretty quickly.) So I guess that means we'll have
to get a little creative as to how we expose these attribute sets to the
client.
This is another very good reason to use an instruction table which is
preprocessed into a usable format: it means that if the internal data
structures change -- and they almost certainly will have to at some
point -- the raw data isn't lost.
Hmm, I have an idea about instruction table. Usually, instruction tables
are encoded with code defined by each decoder/emulator. This method
will show their internal code directly, and is hard to maintain when
the opcode map is updated. Instead of that, I'd like to suggest using
the expressions in the opcode maps in a vender's genuine document (in
this case, Intel/AMD's manual) or www.sandpile.org for instruction
tables.
e.g.
const insn_attr_t onebyte_attr_table[ATTR_TABLE_SIZE] = {
/* 0x00-0x0f */
AT2(Eb,Gb), AT2(Ev,Gv), AT2(Gb,Eb), AT2(Gv,Ev),
AT2(AL,Ib), AT2(rAX,Iz), AT2(ES,i64), AT2(ES,i64),
AT2(Eb,Gb), AT2(Ev,Gv), AT2(Gb,Eb), AT2(Gv,Ev),
AT2(AL,Ib), AT2(rAX,Iz), AT2(CS,i64), AT(ESC),
...
Here, AT and AT2 macros are defined as follows:
#define AT(a) (INAT_OMEXP_##a)
#define AT2(a1, a2) (INAT_OMEXP_##a1 | INAT_OMEXP_##a2)
(OMEXP means Opcode Map Expression)
And each INAT_OMEXP_* is translated into internal format.
#define INAT_OMEXP_Eb INAT_ENCODE_RM(TYPE_MEMREG, SIZE_BYTE)
#define INAT_OMEXP_Gb INAT_ENCODE_REG(TYPE_MEMREG, SIZE_BYTE)
...
This idea will allow everyone to easily maintain instruction tables
by comparing instruction tables with vender's opcode map.
Designing internal instruction tables is harder. Currently, I'm
working on below layout.
Comments are welcome!
Instruction Attribute Encoding
==
Bitmap layout:
[ESC]
0 0 [(padding)][OPFLG][IMM][REG][RGT][RGS][RM][RMT][RMS]
0 1 [(padding)][PFXGRP][PFXEXT][Prefix code]
1 0 [(padding)][EID]
1 1 [(padding)][GID]
ESC(2): Switching normal/escape/group/prefix.
(0:normal opcode, 1:(Legacy)Prefix, 2:Escape, 3:Group)
- Normal opcodes
OPFLG(7): Flag bits: [REX][LPFX][I64][F64][NOPR][EREG][AIMM]
REX(1): Opcode is a REX prefix.
LPFX(1): Opcode can be modified by Last Prefix(SSE2-4)
I64(1): Opcode is invalid in 64bit mode.
F64(1): Oprand is 64bits width in 64bit mode.
NOPR(1): Opcode has no operand.
EREG(1) : Opcode byte encodes Registers
AIMM(1) : Opcode has another 1 byte Immediate(2nd Immediate).
IMM(3): Immediate size bits
(0:none, 1:byte, 2:word, 3:dword, 4:qword, 5:pointer,
6:word/dword, 7:word/dword/qword)
REG(1): Opcode has ModRM 'reg'
RGT(3): ModRM 'reg' type or special operand bits
(0:none,
REG=0: 1:DS/SI
REG=1: 1:GPR, 2:MMX, 3:XMM, 4:DBG, 5:CTR, 6:FP, 7:SR)
RGS(3): ModRM 'reg' or special operand size bits
(GPR: 1:byte, 2:word, 3:dword, 4:qword, 5:N/A, 6:word/dword,
7:word/dword/qword)
(MMX: 3:dword, 4:qword)
(XMM: 2:Scalar-SingleFP, 3:Scaler-DoubleFP, 4:qword, 5:d-qword,
6:Packed-SingleFP, 7:Packed-DoubleFP)
(FP: ?)
(Others: same as GPR)
RM(1) : Opcode has ModRM 'rm'
RMT(3) : ModRM 'rm' type or special operand bits
(0:none,
RM=0: 1:ES/DI
RM=1: 1:GPR, 2:MMX, 3:XMM, 4:Memory, 5:GPR/Mem, 6:MMX/MEM, 7:XMM/Mem)
RMS(3): ModRM 'rm' or special operand size bits. see RGS.
- Legacy prefixes
PFXGRP(4): Prefix group bits: [PGRP1][PGRP2][PGRP3][PGRP4]
PGRP1(1): opcode is prefix group1
PGRP2(1): opcode is prefix group2
PGRP3(1): opcode is prefix group3
PGRP4(1): opcode is prefix group4
PFXEXT(2): Mandatory prefix extent
(0:none, 1:66H, 2:F2H, 3:F3H)
Prefix code(11): Prefix code bits
- Escape opcode
EID(2): Escape code id.
(0:2byte escape, 1:FPU escape, 2:3byte escape1, 3:3byte escape2)
- Group opcode
GID(5): Group Number
(0:Group1, 1:Group1A, 2:Group2, ... 16:Group16)
Thanks,
--
Masami Hiramatsu
Software Engineer
Hitachi
Re: [PATCH -tip 3/6 V4.1] x86: instruction decorder API
Masami Hiramatsu wrote:
Hmm, I have an idea about instruction table. Usually, instruction tables
are encoded with code defined by each decoder/emulator. This method
will show their internal code directly, and is hard to maintain when
the opcode map is updated. Instead of that, I'd like to suggest using
the expressions in the opcode maps in a vender's genuine document (in
this case, Intel/AMD's manual) or www.sandpile.org for instruction
tables.
Yes, we discussed this at the Collab Summit. I think it's the only sane
thing.
e.g.
const insn_attr_t onebyte_attr_table[ATTR_TABLE_SIZE] = {
/* 0x00-0x0f */
AT2(Eb,Gb), AT2(Ev,Gv), AT2(Gb,Eb), AT2(Gv,Ev),
AT2(AL,Ib), AT2(rAX,Iz), AT2(ES,i64), AT2(ES,i64),
AT2(Eb,Gb), AT2(Ev,Gv), AT2(Gb,Eb), AT2(Gv,Ev),
AT2(AL,Ib), AT2(rAX,Iz), AT2(CS,i64), AT(ESC),
...
Here, AT and AT2 macros are defined as follows:
I would suggest using an actual parser, rather than relying on cpp for
this. The parser will be much more powerful, and will make it much
easier to change data structure radically as we discussed.
-hpa
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -tip 3/6 V4.1] x86: instruction decorder API
On Thu, 2009-04-16 at 19:31 -0400, Masami Hiramatsu wrote:
...
Hmm, I have an idea about instruction table. Usually, instruction tables
are encoded with code defined by each decoder/emulator. This method
will show their internal code directly, and is hard to maintain when
the opcode map is updated. Instead of that, I'd like to suggest using
the expressions in the opcode maps in a vender's genuine document (in
this case, Intel/AMD's manual) or www.sandpile.org for instruction
tables.
e.g.
const insn_attr_t onebyte_attr_table[ATTR_TABLE_SIZE] = {
/* 0x00-0x0f */
AT2(Eb,Gb), AT2(Ev,Gv), AT2(Gb,Eb), AT2(Gv,Ev),
AT2(AL,Ib), AT2(rAX,Iz), AT2(ES,i64), AT2(ES,i64),
AT2(Eb,Gb), AT2(Ev,Gv), AT2(Gb,Eb), AT2(Gv,Ev),
AT2(AL,Ib), AT2(rAX,Iz), AT2(CS,i64), AT(ESC),
...
Here, AT and AT2 macros are defined as follows:
#define AT(a) (INAT_OMEXP_##a)
#define AT2(a1, a2) (INAT_OMEXP_##a1 | INAT_OMEXP_##a2)
...
It looks like AT2(Ev,Gv) would yield the same bits as AT2(Gv,Ev). It'd
be nice not to lose the operand-order information. And we'd have to
make clear whether which notation we're using -- src,dest as in the gnu
assembler, or dest,src as in the AMD (and Intel?) manuals.
Jim
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -tip 3/6 V4.1] x86: instruction decorder API
Jim Keniston wrote: It looks like AT2(Ev,Gv) would yield the same bits as AT2(Gv,Ev). It'd be nice not to lose the operand-order information. And we'd have to make clear whether which notation we're using -- src,dest as in the gnu assembler, or dest,src as in the AMD (and Intel?) manuals. Since the information would come from the manuals, I would recommend following them (dst first.) -hpa -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm with OpenBSD 4.5
2009/4/16 Brian Jackson i...@theiggy.com: it's a module option to the kvm option. parm: oos_shadow:bool When I set 'oos_shadow=Y' for kvm-84 module, OpenBSD 4.5 stopped after display 'clock: unknown CMOS layout'. When I set 'oos_shadow=N' for kvm-84 module, OpenBSD 4.5 go farther, stopped after display 'setting ttty flags'. Both dmesg display like this: Apr 17 09:16:58 dl kernel: [47761.218611] __ratelimit: 1216720 messages suppressed Apr 17 09:16:58 dl kernel: [47761.218611] emulation failed (pagetable) rip d0491096 c9 c3 8a 04 -- Dongsheng Song -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm with OpenBSD 4.5
No good news, same as kvm-84 vanilla.
2009/4/17 David S. Ahern daah...@cisco.com:
I believe this is the patch that should fix the problem:
Index: kvm/arch/x86/kvm/mmu.c
===
--- kvm.orig/arch/x86/kvm/mmu.c
+++ kvm/arch/x86/kvm/mmu.c
@@ -1254,7 +1254,7 @@ static struct kvm_mmu_page *kvm_mmu_get_
pgprintk(%s: adding gfn %lx role %x\n, __func__, gfn, role.word);
sp-gfn = gfn;
sp-role = role;
- sp-global = role.cr4_pge;
+ sp-global = 0;
hlist_add_head(sp-hash_link, bucket);
if (!direct) {
if (rmap_write_protect(vcpu-kvm, gfn))
david
Dongsheng Song wrote:
2009/4/16 Brian Jackson i...@theiggy.com:
it's a module option to the kvm option.
parm: oos_shadow:bool
When I set 'oos_shadow=Y' for kvm-84 module, OpenBSD 4.5 stopped
after display 'clock: unknown CMOS layout'.
When I set 'oos_shadow=N' for kvm-84 module, OpenBSD 4.5 go farther,
stopped after display 'setting ttty flags'.
Both dmesg display like this:
Apr 17 09:16:58 dl kernel: [47761.218611] __ratelimit: 1216720
messages suppressed
Apr 17 09:16:58 dl kernel: [47761.218611] emulation failed (pagetable)
rip d0491096 c9 c3 8a 04
--
Dongsheng Song
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm with OpenBSD 4.5
Have you seen this thread:
http://article.gmane.org/gmane.comp.emulators.kvm.devel/28649
It's the one that resulted in these patches by Marcelo:
http://article.gmane.org/gmane.comp.emulators.kvm.devel/30452
http://article.gmane.org/gmane.comp.emulators.kvm.devel/30453
david
Dongsheng Song wrote:
No good news, same as kvm-84 vanilla.
2009/4/17 David S. Ahern daah...@cisco.com:
I believe this is the patch that should fix the problem:
Index: kvm/arch/x86/kvm/mmu.c
===
--- kvm.orig/arch/x86/kvm/mmu.c
+++ kvm/arch/x86/kvm/mmu.c
@@ -1254,7 +1254,7 @@ static struct kvm_mmu_page *kvm_mmu_get_
pgprintk(%s: adding gfn %lx role %x\n, __func__, gfn, role.word);
sp-gfn = gfn;
sp-role = role;
- sp-global = role.cr4_pge;
+ sp-global = 0;
hlist_add_head(sp-hash_link, bucket);
if (!direct) {
if (rmap_write_protect(vcpu-kvm, gfn))
david
Dongsheng Song wrote:
2009/4/16 Brian Jackson i...@theiggy.com:
it's a module option to the kvm option.
parm: oos_shadow:bool
When I set 'oos_shadow=Y' for kvm-84 module, OpenBSD 4.5 stopped
after display 'clock: unknown CMOS layout'.
When I set 'oos_shadow=N' for kvm-84 module, OpenBSD 4.5 go farther,
stopped after display 'setting ttty flags'.
Both dmesg display like this:
Apr 17 09:16:58 dl kernel: [47761.218611] __ratelimit: 1216720
messages suppressed
Apr 17 09:16:58 dl kernel: [47761.218611] emulation failed (pagetable)
rip d0491096 c9 c3 8a 04
--
Dongsheng Song
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm with OpenBSD 4.5
I don't think it's a cr3 OOS optimisation break, as kvm-72 faild too. 2009/4/17 David S. Ahern daah...@cisco.com: Have you seen this thread: http://article.gmane.org/gmane.comp.emulators.kvm.devel/28649 It's the one that resulted in these patches by Marcelo: http://article.gmane.org/gmane.comp.emulators.kvm.devel/30452 http://article.gmane.org/gmane.comp.emulators.kvm.devel/30453 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] return default values for apic probe functions.
As KVM cpus runs on threads, it is possible that
we call kvm_load_registers() from a cpu thread, while the
apic has not yet fully initialized. kvm_load_registers() is called
from ap_main_loop.
This is not a problem when we're starting the whole machine together,
but is a problem for hotplug, since we don't have the protection
of the locks that protect machine initialization. Currently, some executions
of cpu hotplug on rainy sundays fail with a segfault.
Moving apic initialization to before kvm_init_vpcu proved fruitful,
as there are some dependencies involved. (kvm irqchip would fail to
initialize).
This patch provides default values to be used for tpr and apic_base,
that will be returned when the apic is not yet properly initialized.
It is aimed at kvm, where the problem exists, but it could equally be
used for qemu too, if there is agreement.
Signed-off-by: Glauber Costa glom...@redhat.com
---
qemu/hw/apic.c | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/qemu/hw/apic.c b/qemu/hw/apic.c
index b926508..06fb9b5 100644
--- a/qemu/hw/apic.c
+++ b/qemu/hw/apic.c
@@ -301,7 +301,12 @@ uint64_t cpu_get_apic_base(CPUState *env)
#ifdef DEBUG_APIC
printf(cpu_get_apic_base: %016 PRIx64 \n, (uint64_t)s-apicbase);
#endif
-return s-apicbase;
+if (s) {
+return s-apicbase;
+}
+else {
+return 0xfee0 | MSR_IA32_APICBASE_ENABLE;
+}
}
void cpu_set_apic_tpr(CPUX86State *env, uint8_t val)
@@ -314,7 +319,10 @@ void cpu_set_apic_tpr(CPUX86State *env, uint8_t val)
uint8_t cpu_get_apic_tpr(CPUX86State *env)
{
APICState *s = env-apic_state;
-return s-tpr 4;
+if (s)
+return s-tpr 4;
+else
+return 0;
}
/* return -1 if no bit is set */
--
1.5.6.6
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
