Re: your mail
On Thu, Jul 23, 2009 at 11:39:55AM +0530, Haneef Syed wrote: > Is kvm-88 is compatible with linux-2.6.24 kernel..??? > It may be. Some degree of compatibility with older kernels is maintained. Try it. http://www.linux-kvm.org/page/Code -- Gleb. -- 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: your mail
Is kvm-88 is compatible with linux-2.6.24 kernel..??? __ -- 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: your mail
On Thu, Jul 23, 2009 at 11:08:41AM +0530, Haneef Syed wrote: > HI All, > > I have taken kvm-22 with linux-2.6.24 kernel but when ever i install guest > through qemu bins, system hangs. > > In dmesg it prints as "Unable to handle NULL derefrencing pointer". > > Please suggest me why it is behaving like this > I would suggest you to use more recent KVM. The latest one is kvm-88. There were a couple of bug fixes and enhancements in those 66 version. -- Gleb. -- 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 v2 5/6] remove kvm_specific kvm_out* functions
On Wed, Jul 22, 2009 at 04:50:28PM -0300, Marcelo Tosatti wrote:
> Gleb,
>
> Can you please review this to make sure the handling in acpi.c
> is correct and complete?
>
The handling in acpi.c is the same except this bit:
case 0: {
cpu_outb(0, 0xb3, 0);
break;
But this doesn't make sense according to a spec and if it is needed
(which I doubt) it should be handled in acpi.c too.
> On Tue, Jul 21, 2009 at 06:13:11PM -0400, Glauber Costa wrote:
> > As example of what was already done with inb.
> > This is a little bit more tricky, because of SMM, but those
> > bits are handled directly in apic anyway.
> >
> > Signed-off-by: Glauber Costa
> > ---
> > qemu-kvm.c | 60
> > +++-
> > 1 files changed, 3 insertions(+), 57 deletions(-)
> >
> > diff --git a/qemu-kvm.c b/qemu-kvm.c
> > index cef522d..0724c28 100644
> > --- a/qemu-kvm.c
> > +++ b/qemu-kvm.c
> > @@ -95,55 +95,6 @@ static int kvm_debug(void *opaque, void *data,
> > }
> > #endif
> >
> > -#define PM_IO_BASE 0xb000
> > -
> > -static int kvm_outb(void *opaque, uint16_t addr, uint8_t data)
> > -{
> > -if (addr == 0xb2) {
> > - switch (data) {
> > - case 0: {
> > - cpu_outb(0, 0xb3, 0);
> > - break;
> > - }
> > - case 0xf0: {
> > - unsigned x;
> > -
> > - /* enable acpi */
> > - x = cpu_inw(0, PM_IO_BASE + 4);
> > - x &= ~1;
> > - cpu_outw(0, PM_IO_BASE + 4, x);
> > - break;
> > - }
> > - case 0xf1: {
> > - unsigned x;
> > -
> > - /* enable acpi */
> > - x = cpu_inw(0, PM_IO_BASE + 4);
> > - x |= 1;
> > - cpu_outw(0, PM_IO_BASE + 4, x);
> > - break;
> > - }
> > - default:
> > - break;
> > - }
> > - return 0;
> > -}
> > -cpu_outb(0, addr, data);
> > -return 0;
> > -}
> > -
> > -static int kvm_outw(void *opaque, uint16_t addr, uint16_t data)
> > -{
> > -cpu_outw(0, addr, data);
> > -return 0;
> > -}
> > -
> > -static int kvm_outl(void *opaque, uint16_t addr, uint32_t data)
> > -{
> > -cpu_outl(0, addr, data);
> > -return 0;
> > -}
> > -
> > int kvm_mmio_read(void *opaque, uint64_t addr, uint8_t *data, int len)
> > {
> > cpu_physical_memory_rw(addr, data, len, 0);
> > @@ -825,14 +776,12 @@ static int handle_io(kvm_vcpu_context_t vcpu)
> > struct kvm_run *run = vcpu->run;
> > kvm_context_t kvm = vcpu->kvm;
> > uint16_t addr = run->io.port;
> > - int r;
> > int i;
> > void *p = (void *)run + run->io.data_offset;
> >
> > for (i = 0; i < run->io.count; ++i) {
> > switch (run->io.direction) {
> > case KVM_EXIT_IO_IN:
> > - r = 0;
> > switch (run->io.size) {
> > case 1:
> > *(uint8_t *)p = cpu_inb(kvm->opaque, addr);
> > @@ -851,16 +800,13 @@ static int handle_io(kvm_vcpu_context_t vcpu)
> > case KVM_EXIT_IO_OUT:
> > switch (run->io.size) {
> > case 1:
> > - r = kvm_outb(kvm->opaque, addr,
> > -*(uint8_t *)p);
> > +cpu_outb(kvm->opaque, addr, *(uint8_t *)p);
> > break;
> > case 2:
> > - r = kvm_outw(kvm->opaque, addr,
> > -*(uint16_t *)p);
> > + cpu_outw(kvm->opaque, addr, *(uint16_t *)p);
> > break;
> > case 4:
> > - r = kvm_outl(kvm->opaque, addr,
> > -*(uint32_t *)p);
> > + cpu_outl(kvm->opaque, addr, *(uint32_t *)p);
> > break;
> > default:
> > fprintf(stderr, "bad I/O size %d\n",
> > run->io.size);
> > --
> > 1.6.2.2
> >
> > --
> > 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
--
Gleb.
--
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
[no subject]
HI All, I have taken kvm-22 with linux-2.6.24 kernel but when ever i install guest through qemu bins, system hangs. In dmesg it prints as "Unable to handle NULL derefrencing pointer". Please suggest me why it is behaving like this __ -- 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 2/2] virtio: fix double free_irq
On Wed, 22 Jul 2009 01:29:25 am Michael S. Tsirkin wrote:
> - if (info->vector != VIRTIO_MSI_NO_VECTOR)
> + if (info->vector != VIRTIO_MSI_NO_VECTOR) {
> free_irq(vp_dev->msix_entries[info->vector].vector, vq);
> + --vp_dev->msix_used_vectors;
> + }
>
This only works because the only current caller of vp_del_vq is vp_del_vqs, so
msix_used_vectors will be 0 after all the queues have been freed.
Make up your mind. Either find_vq allocates and del_vq frees, or it's find_vqs
and del_vqs. I suggest the former, and setting the value VIRTIO_MSI_NO_VECTOR
to indicate it's already freed. I think with some cleanups, that loop in
vp_free_vectors might go away, too.
Rusty.
--
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] virtio: fix memory leak on device removal
On Wed, 22 Jul 2009 01:29:09 am Michael S. Tsirkin wrote: > Free up msi vector tables. Michael, this papers over the bug, but doesn't actually fix the problem. The problem is that vp_free_vectors() does not do the reverse of vp_request_vectors. If the author (you) can't get it right, what hope the rest of us? Indeed, if you look harder, you'll see another leak caused by this problem, which your patch *didn't* fix. Thanks, Rusty. -- 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: [Autotest] [KVM-AUTOTEST PATCH 05/17] Remove kvm_spawn and run_bg() from kvm_utils.py.
Applied.
On Mon, Jul 20, 2009 at 12:07 PM, Michael Goldish wrote:
> These are now provided by kvm_subprocess.py.
>
> Signed-off-by: Michael Goldish
> ---
> client/tests/kvm/kvm_utils.py | 477
> +
> 1 files changed, 2 insertions(+), 475 deletions(-)
>
> diff --git a/client/tests/kvm/kvm_utils.py b/client/tests/kvm/kvm_utils.py
> index fb587c5..9391874 100644
> --- a/client/tests/kvm/kvm_utils.py
> +++ b/client/tests/kvm/kvm_utils.py
> @@ -227,390 +227,8 @@ def check_kvm_source_dir(source_dir):
> raise error.TestError("Unknown source dir layout, cannot proceed.")
>
>
> -# The following are a class and functions used for SSH, SCP and Telnet
> -# communication with guests.
> -
> -class kvm_spawn:
> - """
> - This class is used for spawning and controlling a child process.
> - """
> -
> - def __init__(self, command, linesep="\n"):
> - """
> - Initialize the class and run command as a child process.
> -
> - �...@param command: Command that will be run.
> - �...@param linesep: Line separator for the given platform.
> - """
> - self.exitstatus = None
> - self.linesep = linesep
> - (pid, fd) = pty.fork()
> - if pid == 0:
> - os.execv("/bin/sh", ["/bin/sh", "-c", command])
> - else:
> - self.pid = pid
> - self.fd = fd
> -
> -
> - def set_linesep(self, linesep):
> - """
> - Sets the line separator string (usually "\\n").
> -
> - �...@param linesep: Line separator character.
> - """
> - self.linesep = linesep
> -
> -
> - def is_responsive(self, timeout=5.0):
> - """
> - Return True if the session is responsive.
> -
> - Send a newline to the child process (e.g. SSH or Telnet) and read
> some
> - output using read_nonblocking.
> - If all is OK, some output should be available (e.g. the shell
> prompt).
> - In that case return True. Otherwise return False.
> -
> - �...@param timeout: Timeout that will happen before we consider the
> - process unresponsive
> - """
> - self.read_nonblocking(timeout=0.1)
> - self.sendline()
> - output = self.read_nonblocking(timeout=timeout)
> - if output.strip():
> - return True
> - return False
> -
> -
> - def poll(self):
> - """
> - If the process exited, return its exit status. Otherwise return None.
> - The exit status is stored for use in subsequent calls.
> - """
> - if self.exitstatus != None:
> - return self.exitstatus
> - pid, status = os.waitpid(self.pid, os.WNOHANG)
> - if pid:
> - self.exitstatus = os.WEXITSTATUS(status)
> - return self.exitstatus
> - else:
> - return None
> -
> -
> - def close(self):
> - """
> - Close the session (close the process filedescriptors and kills the
> - process ID), and return the exit status.
> - """
> - try:
> - os.close(self.fd)
> - os.kill(self.pid, signal.SIGTERM)
> - except OSError:
> - pass
> - return self.poll()
> -
> -
> - def sendline(self, str=""):
> - """
> - Sends a string followed by a line separator to the child process.
> -
> - �...@param str: String that will be sent to the child process.
> - """
> - try:
> - os.write(self.fd, str + self.linesep)
> - except OSError:
> - pass
> -
> -
> - def read_nonblocking(self, timeout=1.0):
> - """
> - Read from child until there is nothing to read for timeout seconds.
> -
> - �...@param timeout: Time (seconds) of wait before we give up reading
> from
> - the child process.
> - """
> - data = ""
> - while True:
> - r, w, x = select.select([self.fd], [], [], timeout)
> - if self.fd in r:
> - try:
> - data += os.read(self.fd, 1024)
> - except OSError:
> - return data
> - else:
> - return data
> -
> -
> - def match_patterns(self, str, patterns):
> - """
> - Match str against a list of patterns.
> -
> - Return the index of the first pattern that matches a substring of
> str.
> - None and empty strings in patterns are ignored.
> - If no match is found, return None.
> -
> - �...@param patterns: List of strings (regular expression patterns).
> - """
> - for i in range(len(patterns)):
> - if not patterns[i]:
> - continue
> - exp = re.compile(patterns[i])
> - if exp.search(str):
> - return i
> -
> -
> - def read_until_output_matches(self, patterns, filter=lambda(x):x,
> - timeout=30.0, internal_timeout=1.0,
>
Re: [Autotest] [KVM-AUTOTEST PATCH 04/17] Modify run_autotest() in kvm_tests.py to use the new kvm_subprocess module.
Applied. On Mon, Jul 20, 2009 at 12:07 PM, Michael Goldish wrote: > Signed-off-by: Michael Goldish > --- > client/tests/kvm/kvm_tests.py | 9 + > 1 files changed, 5 insertions(+), 4 deletions(-) > > diff --git a/client/tests/kvm/kvm_tests.py b/client/tests/kvm/kvm_tests.py > index 2d11fed..5991aed 100644 > --- a/client/tests/kvm/kvm_tests.py > +++ b/client/tests/kvm/kvm_tests.py > @@ -1,6 +1,6 @@ > import time, os, logging > from autotest_lib.client.common_lib import utils, error > -import kvm_utils, ppm_utils, scan_results > +import kvm_utils, kvm_subprocess, ppm_utils, scan_results > > """ > KVM test definitions. > @@ -274,15 +274,16 @@ def run_autotest(test, params, env): > cmd += " --exclude=*.pyc" > cmd += " --exclude=*.svn" > cmd += " --exclude=*.git" > - kvm_utils.run_bg(cmd % (test.bindir, tarred_autotest_path), timeout=30) > + kvm_subprocess.run_fg(cmd % (test.bindir, tarred_autotest_path), > timeout=30) > > # tar the contents of bindir/autotest/tests/ > cmd = "cd %s; tar cvjf %s %s/*" > cmd += " --exclude=*.pyc" > cmd += " --exclude=*.svn" > cmd += " --exclude=*.git" > - kvm_utils.run_bg(cmd % (os.path.join(test.bindir, "autotest", "tests"), > - tarred_test_path, test_name), timeout=30) > + kvm_subprocess.run_fg(cmd % > + (os.path.join(test.bindir, "autotest", "tests"), > + tarred_test_path, test_name), timeout=30) > > # Check if we need to copy autotest.tar.bz2 > copy = False > -- > 1.5.4.1 > > ___ > Autotest mailing list > autot...@test.kernel.org > http://test.kernel.org/cgi-bin/mailman/listinfo/autotest > -- Lucas Meneghel -- 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: [Autotest] [KVM-AUTOTEST PATCH 03/17] Modify remote_login and remote_scp in kvm_utils to use kvm_subprocess
Applied.
On Thu, Jul 23, 2009 at 1:02 AM, Lucas Meneghel Rodrigues
wrote:
> On Mon, Jul 20, 2009 at 12:07 PM, Michael Goldish wrote:
>> Also remove a reference to kvm_log that was left behind.
>>
>> Signed-off-by: Michael Goldish
>> ---
>> client/tests/kvm/kvm_utils.py | 13 -
>> 1 files changed, 8 insertions(+), 5 deletions(-)
>>
>> diff --git a/client/tests/kvm/kvm_utils.py b/client/tests/kvm/kvm_utils.py
>> index b2b0d1a..fb587c5 100644
>> --- a/client/tests/kvm/kvm_utils.py
>> +++ b/client/tests/kvm/kvm_utils.py
>> @@ -2,6 +2,7 @@ import md5, thread, subprocess, time, string, random,
>> socket, os, signal, pty
>> import select, re, logging
>> from autotest_lib.client.bin import utils
>> from autotest_lib.client.common_lib import error
>> +import kvm_subprocess
>>
>> """
>> KVM test utility functions.
>> @@ -631,8 +632,9 @@ def remote_login(command, password, prompt,
>> linesep="\n", timeout=10):
>>
>> @return Return the kvm_spawn object on success and None on failure.
>> """
>> - sub = kvm_spawn(command, linesep)
>> - sub.set_prompt(prompt)
>> + sub = kvm_subprocess.kvm_shell_session(command,
>> + linesep=linesep,
>> + prompt=prompt)
>>
>> password_prompt_count = 0
>>
>> @@ -698,7 +700,7 @@ def remote_scp(command, password, timeout=300,
>> login_timeout=10):
>>
>> @return: True if the transfer succeeds and False on failure.
>> """
>> - sub = kvm_spawn(command)
>> + sub = kvm_subprocess.kvm_expect(command)
>>
>> password_prompt_count = 0
>> _timeout = login_timeout
>> @@ -729,9 +731,10 @@ def remote_scp(command, password, timeout=300,
>> login_timeout=10):
>> sub.close()
>> return False
>> else: # match == None
>> - logging.debug("Timeout or process terminated")
>> + logging.debug("Timeout elapsed or process terminated")
>> + status = sub.get_status()
>> sub.close()
>> - return sub.poll() == 0
>> + return status == 0
>>
>>
>> def scp_to_remote(host, port, username, password, local_path, remote_path,
>> --
>> 1.5.4.1
>>
>> ___
>> Autotest mailing list
>> autot...@test.kernel.org
>> http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
>>
>
>
>
> --
> Lucas Meneghel
>
--
Lucas Meneghel
--
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: [Autotest] [KVM-AUTOTEST PATCH 03/17] Modify remote_login and remote_scp in kvm_utils to use kvm_subprocess
On Mon, Jul 20, 2009 at 12:07 PM, Michael Goldish wrote:
> Also remove a reference to kvm_log that was left behind.
>
> Signed-off-by: Michael Goldish
> ---
> client/tests/kvm/kvm_utils.py | 13 -
> 1 files changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/client/tests/kvm/kvm_utils.py b/client/tests/kvm/kvm_utils.py
> index b2b0d1a..fb587c5 100644
> --- a/client/tests/kvm/kvm_utils.py
> +++ b/client/tests/kvm/kvm_utils.py
> @@ -2,6 +2,7 @@ import md5, thread, subprocess, time, string, random, socket,
> os, signal, pty
> import select, re, logging
> from autotest_lib.client.bin import utils
> from autotest_lib.client.common_lib import error
> +import kvm_subprocess
>
> """
> KVM test utility functions.
> @@ -631,8 +632,9 @@ def remote_login(command, password, prompt, linesep="\n",
> timeout=10):
>
> @return Return the kvm_spawn object on success and None on failure.
> """
> - sub = kvm_spawn(command, linesep)
> - sub.set_prompt(prompt)
> + sub = kvm_subprocess.kvm_shell_session(command,
> + linesep=linesep,
> + prompt=prompt)
>
> password_prompt_count = 0
>
> @@ -698,7 +700,7 @@ def remote_scp(command, password, timeout=300,
> login_timeout=10):
>
> @return: True if the transfer succeeds and False on failure.
> """
> - sub = kvm_spawn(command)
> + sub = kvm_subprocess.kvm_expect(command)
>
> password_prompt_count = 0
> _timeout = login_timeout
> @@ -729,9 +731,10 @@ def remote_scp(command, password, timeout=300,
> login_timeout=10):
> sub.close()
> return False
> else: # match == None
> - logging.debug("Timeout or process terminated")
> + logging.debug("Timeout elapsed or process terminated")
> + status = sub.get_status()
> sub.close()
> - return sub.poll() == 0
> + return status == 0
>
>
> def scp_to_remote(host, port, username, password, local_path, remote_path,
> --
> 1.5.4.1
>
> ___
> Autotest mailing list
> autot...@test.kernel.org
> http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
>
--
Lucas Meneghel
--
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] Update qemu-kvm to allow a larger BIOS image.
On Thursday 23 July 2009 03:04:33 Cristi Magherusan wrote: > On Thu, 2009-07-16 at 10:57 -0700, Jordan Justen wrote: > > On Wed, Jul 15, 2009 at 10:37 PM, Sheng Yang wrote: > > > Make sense to me. So what's mattered here is not bios, but qemu-kvm and > > > kvm code. The user can replace bios binary by UEFI binary easily, but > > > not with kvm related part. > > > > > > I realized you still need separate the qemu-kvm patch into two: one for > > > bios and another for qemu. > > > > Okay, I will split this change apart. > > > > > And I just hope this modification won't break some old > > > OS(any OS got assumption about bios size? I think Tiano team should > > > have idea on it)... > > > > I don't think the OS should care about the bios size, but it is > > important to update the INT15-E820 memory ranges to help > > make sure the OS knows which regions are in use. > > > > Even without the E820 change, I think it would be unlikely > > for an OS to try utilize these memory regions, but it is > > definitely better to properly describe it. > > Hello, > > I don't know if I get this right, but is it enough to apply this patch > to KVM-userspace, or do I also need to have a patched kernel in order to > get large images (my image is 4MB) to work in KVM? > You need a patched KVM kernel modules for this. And you can use Jordan's patch currently(http://article.gmane.org/gmane.comp.emulators.kvm.devel/37344). The first one for BIOS(apply to qemu-kvm tree), second of qemu-kvm, and the third for KVM modules. -- regards Yang, Sheng -- 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: [Autotest] [KVM-AUTOTEST PATCH 02/17] Modify kvm_vm and kvm_preprocessing to use the new kvm_subprocess module
Looks good to me. Applied.
On Mon, Jul 20, 2009 at 12:07 PM, Michael Goldish wrote:
> Signed-off-by: Michael Goldish
> ---
> client/tests/kvm/kvm_preprocessing.py | 27 ++--
> client/tests/kvm/kvm_vm.py | 111 +++-
> 2 files changed, 59 insertions(+), 79 deletions(-)
>
> diff --git a/client/tests/kvm/kvm_preprocessing.py
> b/client/tests/kvm/kvm_preprocessing.py
> index 80d7be8..7b97f00 100644
> --- a/client/tests/kvm/kvm_preprocessing.py
> +++ b/client/tests/kvm/kvm_preprocessing.py
> @@ -1,7 +1,7 @@
> import sys, os, time, commands, re, logging, signal
> from autotest_lib.client.bin import test
> from autotest_lib.client.common_lib import error
> -import kvm_vm, kvm_utils
> +import kvm_vm, kvm_utils, kvm_subprocess
>
>
> def preprocess_image(test, params):
> @@ -75,7 +75,7 @@ def preprocess_vm(test, params, env, name):
> qemu_path,
> image_dir,
> iso_dir):
> - logging.debug("VM's qemu command differs from requested one;"
> + logging.debug("VM's qemu command differs from requested one; "
> "restarting it...")
> start_vm = True
>
> @@ -158,13 +158,11 @@ def process_command(test, params, env, command,
> command_timeout,
> # execute command
> logging.info("Executing command '%s'..." % command)
> timeout = int(command_timeout)
> - (status, pid, output) = kvm_utils.run_bg("cd %s; %s" % (test.bindir,
> + (status, output) = kvm_subprocess.run_fg("cd %s; %s" % (test.bindir,
> command),
> - None,
> logging.debug,
> - "(command) ",
> - timeout =
> timeout)
> + logging.debug, "(command) ",
> + timeout=timeout)
> if status != 0:
> - kvm_utils.safe_kill(pid, signal.SIGTERM)
> logging.warn("Custom processing command failed: '%s'..." % command)
> if command_noncritical != "yes":
> raise error.TestError("Custom processing command failed")
> @@ -204,17 +202,6 @@ def preprocess(test, params, env):
> @param params: A dict containing all VM and image parameters.
> @param env: The environment (a dict-like object).
> """
> - # Verify the identities of all living VMs
> - for vm in env.values():
> - if not kvm_utils.is_vm(vm):
> - continue
> - if vm.is_dead():
> - continue
> - if not vm.verify_process_identity():
> - logging.debug("VM '%s' seems to have been replaced by another"
> - " process" % vm.name)
> - vm.pid = None
> -
> # Destroy and remove VMs that are no longer needed in the environment
> requested_vms = kvm_utils.get_sub_dict_names(params, "vms")
> for key in env.keys():
> @@ -282,8 +269,8 @@ def postprocess(test, params, env):
> # Remove them all
> logging.debug("'keep_ppm_files' not specified; removing all PPM files"
> " from results dir...")
> - kvm_utils.run_bg("rm -vf %s" % os.path.join(test.debugdir, "*.ppm"),
> - None, logging.debug, "(rm) ", timeout=5.0)
> + rm_cmd = "rm -vf %s" % os.path.join(test.debugdir, "*.ppm")
> + kvm_subprocess.run_fg(rm_cmd, logging.debug, "(rm) ", timeout=5.0)
>
> #execute any post_commands
> if params.get("post_command"):
> diff --git a/client/tests/kvm/kvm_vm.py b/client/tests/kvm/kvm_vm.py
> index 48f2916..8bc2403 100644
> --- a/client/tests/kvm/kvm_vm.py
> +++ b/client/tests/kvm/kvm_vm.py
> @@ -1,6 +1,6 @@
> #!/usr/bin/python
> import time, socket, os, logging, fcntl
> -import kvm_utils
> +import kvm_utils, kvm_subprocess
>
> """
> Utility classes and functions to handle Virtual Machine creation using qemu.
> @@ -54,17 +54,22 @@ def create_image(params, qemu_img_path, image_dir):
> qemu_img_cmd += " %s" % size
>
> logging.debug("Running qemu-img command:\n%s" % qemu_img_cmd)
> - (status, pid, output) = kvm_utils.run_bg(qemu_img_cmd, None,
> - logging.debug, "(qemu-img) ",
> - timeout=30)
> + (status, output) = kvm_subprocess.run_fg(qemu_img_cmd, logging.debug,
> + "(qemu-img) ", timeout=30)
>
> - if status:
> - logging.debug("qemu-img exited with status %d" % status)
> - logging.error("Could not create image %s" % image_filename)
> + if status is None:
> + logging.error("Timeout elapsed while waiting for qemu-img command "
> +
[PATCH] fix mce check extension
Because a patch got into marcelo's tree before mine did, I forgot
to convert one user of kvm_check_extension. Here's the fix for it.
Signed-off-by: Glauber Costa
---
qemu-kvm-x86.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/qemu-kvm-x86.c b/qemu-kvm-x86.c
index e4ae582..492dbc5 100644
--- a/qemu-kvm-x86.c
+++ b/qemu-kvm-x86.c
@@ -1338,7 +1338,7 @@ int kvm_arch_qemu_init_env(CPUState *cenv)
#ifdef KVM_CAP_MCE
if (((cenv->cpuid_version >> 8)&0xF) >= 6
&& (cenv->cpuid_features&(CPUID_MCE|CPUID_MCA)) ==
(CPUID_MCE|CPUID_MCA)
-&& kvm_check_extension(kvm_context, KVM_CAP_MCE) > 0) {
+&& kvm_check_extension(kvm_state, KVM_CAP_MCE) > 0) {
uint64_t mcg_cap;
int banks;
--
1.6.2.2
--
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-kmod: Fix including of arch/*/kvm/trace.h
When building against a split kernel, we have to add its source path to
the include path. Otherwise arch/*/kvm/trace.h cannot be found.
Signed-off-by: Jan Kiszka
---
Makefile |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index ad08c45..4c813a6 100644
--- a/Makefile
+++ b/Makefile
@@ -28,7 +28,7 @@ all:: prerequisite
$(MAKE) -C $(KERNELDIR) M=`pwd` \
LINUXINCLUDE="-I`pwd`/include -Iinclude \
$(if $(KERNELSOURCEDIR),\
- -Iinclude2 -I$(KERNELSOURCEDIR)/include
-I$(KERNELSOURCEDIR)/arch/${ARCH_DIR}/include, \
+ -Iinclude2 -I$(KERNELSOURCEDIR)/include
-I$(KERNELSOURCEDIR)/arch/${ARCH_DIR}/include -I$(KERNELSOURCEDIR), \
-Iarch/${ARCH_DIR}/include) -I`pwd`/include-compat \
-include include/linux/autoconf.h \
-include `pwd`/$(ARCH_DIR)/external-module-compat.h
$(module_defines)" \
signature.asc
Description: OpenPGP digital signature
[PATCH] KVM: VMX: Fix locking order in handle_invalid_guest_state
Release and re-acquire preemption and IRQ lock in the same order as
vcpu_enter_guest does.
Signed-off-by: Jan Kiszka
---
arch/x86/kvm/vmx.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index d75c271..4f914c3 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -3324,8 +3324,8 @@ static void handle_invalid_guest_state(struct kvm_vcpu
*vcpu,
struct vcpu_vmx *vmx = to_vmx(vcpu);
enum emulation_result err = EMULATE_DONE;
- preempt_enable();
local_irq_enable();
+ preempt_enable();
while (!guest_state_valid(vcpu)) {
err = emulate_instruction(vcpu, kvm_run, 0, 0, 0);
@@ -3344,8 +3344,8 @@ static void handle_invalid_guest_state(struct kvm_vcpu
*vcpu,
schedule();
}
- local_irq_disable();
preempt_disable();
+ local_irq_disable();
vmx->invalid_state_emulation_result = err;
}
signature.asc
Description: OpenPGP digital signature
[PATCH] KVM: VMX: Avoid to return ENOTSUPP to userland
Choose some allowed error values for the cases VMX returned ENOTSUPP so
far as these values could be returned by the KVM_RUN IOCTL.
Signed-off-by: Jan Kiszka
---
arch/x86/kvm/vmx.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 7a8d464..d75c271 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -3132,7 +3132,7 @@ static int handle_apic_access(struct kvm_vcpu *vcpu,
struct kvm_run *kvm_run)
printk(KERN_ERR
"Fail to handle apic access vmexit! Offset is 0x%lx\n",
offset);
- return -ENOTSUPP;
+ return -ENOEXEC;
}
return 1;
}
@@ -3201,7 +3201,7 @@ static int handle_ept_violation(struct kvm_vcpu *vcpu,
struct kvm_run *kvm_run)
if (exit_qualification & (1 << 6)) {
printk(KERN_ERR "EPT: GPA exceeds GAW!\n");
- return -ENOTSUPP;
+ return -EINVAL;
}
gla_validity = (exit_qualification >> 7) & 0x3;
signature.asc
Description: OpenPGP digital signature
Re: [Autotest] [KVM-AUTOTEST PATCH 01/17] Add new module kvm_subprocess
Ok, I have made minor remarks for the first version of this module http://codereview.appspot.com/79042/diff/1/4 and Michael either commented or addressed the questions. I am going to commit this new module. Thanks for your work, Michael! On Mon, Jul 20, 2009 at 12:07 PM, Michael Goldish wrote: > This module is intended to be used for controlling all child processes in KVM > tests: both QEMU processes and SSH/SCP/Telnet processes. Processes started > with > this module keep running and can be interacted with even after the parent > process exits. > > The current run_bg() utility tracks a child process as long as the parent > process is running. When the parent process exits, the tracking thread > terminates and cannot resume when needed. > > Currently SSH/SCP/Telnet communication is handled by kvm_utils.kvm_spawn, > which > does not allow the child process to run after the parent process exits. Thus, > open SSH/SCP/Telnet sessions cannot be reused by tests following the one in > which they are opened. > > The new module provides a solution to these two problems, and also saves some > code by reusing common code required both for QEMU processes and > SSH/SCP/Telnet > processes. > > Signed-off-by: Michael Goldish > --- > client/tests/kvm/kvm_subprocess.py | 1146 > > 1 files changed, 1146 insertions(+), 0 deletions(-) > create mode 100644 client/tests/kvm/kvm_subprocess.py > > diff --git a/client/tests/kvm/kvm_subprocess.py > b/client/tests/kvm/kvm_subprocess.py > new file mode 100644 > index 000..413bdaa > --- /dev/null > +++ b/client/tests/kvm/kvm_subprocess.py > @@ -0,0 +1,1146 @@ > +#!/usr/bin/python > +import sys, subprocess, pty, select, os, time, signal, re, termios, fcntl > +import threading, logging, commands > +import common, kvm_utils > + > +""" > +A class and functions used for running and controlling child processes. > + > +...@copyright: 2008-2009 Red Hat Inc. > +""" > + > + > +def run_bg(command, termination_func=None, output_func=None, > output_prefix="", > + timeout=1.0): > + """ > + Run command as a subprocess. Call output_func with each line of output > + from the subprocess (prefixed by output_prefix). Call termination_func > + when the subprocess terminates. Return when timeout expires or when the > + subprocess exits -- whichever occurs first. > + > + �...@brief: Run a subprocess in the background and collect its output and > + exit status. > + > + �...@param command: The shell command to execute > + �...@param termination_func: A function to call when the process > terminates > + (should take an integer exit status parameter) > + �...@param output_func: A function to call with each line of output from > + the subprocess (should take a string parameter) > + �...@param output_prefix: A string to pre-pend to each line of the output, > + before passing it to stdout_func > + �...@param timeout: Time duration (in seconds) to wait for the subprocess > to > + terminate before returning > + > + �...@return: A kvm_tail object. > + """ > + process = kvm_tail(command=command, > + termination_func=termination_func, > + output_func=output_func, > + output_prefix=output_prefix) > + > + end_time = time.time() + timeout > + while time.time() < end_time and process.is_alive(): > + time.sleep(0.1) > + > + return process > + > + > +def run_fg(command, output_func=None, output_prefix="", timeout=1.0): > + """ > + Run command as a subprocess. Call output_func with each line of output > + from the subprocess (prefixed by prefix). Return when timeout expires or > + when the subprocess exits -- whichever occurs first. If timeout expires > + and the subprocess is still running, kill it before returning. > + > + �...@brief: Run a subprocess in the foreground and collect its output and > + exit status. > + > + �...@param command: The shell command to execute > + �...@param output_func: A function to call with each line of output from > + the subprocess (should take a string parameter) > + �...@param output_prefix: A string to pre-pend to each line of the output, > + before passing it to stdout_func > + �...@param timeout: Time duration (in seconds) to wait for the subprocess > to > + terminate before killing it and returning > + > + �...@return: A 2-tuple containing the exit status of the process and its > + STDOUT/STDERR output. If timeout expires before the process > + terminates, the returned status is None. > + """ > + process = run_bg(command, None, output_func, output_prefix, timeout) > + output = process.get_output() > + if process.is_alive(): > + status = None > + else: > + status = process.get_status() > + process.close() > + return (stat
Re: [PATCH 1/2] qemu-kvm: msix table update thinko fix
On Wed, Jul 22, 2009 at 05:41:13PM +0300, Michael S. Tsirkin wrote:
> over the old one. Current code gets it wrong, and only works because
> it's uncommon for guests to change MSI tables.
>
> Signed-off-by: Michael S. Tsirkin
> ---
> qemu-kvm.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/qemu-kvm.c b/qemu-kvm.c
> index 60e5eac..cebaa65 100644
> --- a/qemu-kvm.c
> +++ b/qemu-kvm.c
> @@ -1552,7 +1552,7 @@ int kvm_update_routing_entry(kvm_context_t kvm,
> if (e->u.msi.address_lo == entry->u.msi.address_lo &&
> e->u.msi.address_hi == entry->u.msi.address_hi &&
> e->u.msi.data == entry->u.msi.data) {
> -memcpy(&e->u.msi, &entry->u.msi, sizeof e->u.msi);
> +memcpy(&e->u.msi, &newentry->u.msi, sizeof e->u.msi);
> return 0;
> }
> break;
Non-msi case seems to suffer from the same problem?
--
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 v2 3/6] remove kvm_abi variable
On Tue, Jul 21, 2009 at 06:13:09PM -0400, Glauber Costa wrote: > We're not using this for anything > > Signed-off-by: Glauber Costa > --- > qemu-kvm.c |3 --- > 1 files changed, 0 insertions(+), 3 deletions(-) > > diff --git a/qemu-kvm.c b/qemu-kvm.c > index 8eeace4..a8298e4 100644 > --- a/qemu-kvm.c > +++ b/qemu-kvm.c > @@ -43,7 +43,6 @@ int kvm_pit = 1; > int kvm_pit_reinject = 1; > int kvm_nested = 0; > > - > static KVMState *kvm_state; > kvm_context_t kvm_context; > > @@ -79,7 +78,6 @@ static LIST_HEAD(, ioperm_data) ioperm_head; > > #define ALIGN(x, y) (((x)+(y)-1) & ~((y)-1)) > > -int kvm_abi = EXPECTED_KVM_API_VERSION; > int kvm_page_size; > > #ifdef KVM_CAP_SET_GUEST_DEBUG > @@ -429,7 +427,6 @@ int kvm_init(int smp_cpus) > fprintf(stderr, "kvm userspace version too old\n"); > goto out_close; > } > - kvm_abi = r; > kvm_page_size = getpagesize(); > kvm_state = qemu_mallocz(sizeof(*kvm_state)); > kvm_context = &kvm_state->kvm_context; > -- Forgot qemu-kvm.h? Applied 1,2,3 and 5 (hopefully nobody outside vl.c is playing with stopped/stop/created?). -- 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 v2 5/6] remove kvm_specific kvm_out* functions
Gleb,
Can you please review this to make sure the handling in acpi.c
is correct and complete?
On Tue, Jul 21, 2009 at 06:13:11PM -0400, Glauber Costa wrote:
> As example of what was already done with inb.
> This is a little bit more tricky, because of SMM, but those
> bits are handled directly in apic anyway.
>
> Signed-off-by: Glauber Costa
> ---
> qemu-kvm.c | 60
> +++-
> 1 files changed, 3 insertions(+), 57 deletions(-)
>
> diff --git a/qemu-kvm.c b/qemu-kvm.c
> index cef522d..0724c28 100644
> --- a/qemu-kvm.c
> +++ b/qemu-kvm.c
> @@ -95,55 +95,6 @@ static int kvm_debug(void *opaque, void *data,
> }
> #endif
>
> -#define PM_IO_BASE 0xb000
> -
> -static int kvm_outb(void *opaque, uint16_t addr, uint8_t data)
> -{
> -if (addr == 0xb2) {
> - switch (data) {
> - case 0: {
> - cpu_outb(0, 0xb3, 0);
> - break;
> - }
> - case 0xf0: {
> - unsigned x;
> -
> - /* enable acpi */
> - x = cpu_inw(0, PM_IO_BASE + 4);
> - x &= ~1;
> - cpu_outw(0, PM_IO_BASE + 4, x);
> - break;
> - }
> - case 0xf1: {
> - unsigned x;
> -
> - /* enable acpi */
> - x = cpu_inw(0, PM_IO_BASE + 4);
> - x |= 1;
> - cpu_outw(0, PM_IO_BASE + 4, x);
> - break;
> - }
> - default:
> - break;
> - }
> - return 0;
> -}
> -cpu_outb(0, addr, data);
> -return 0;
> -}
> -
> -static int kvm_outw(void *opaque, uint16_t addr, uint16_t data)
> -{
> -cpu_outw(0, addr, data);
> -return 0;
> -}
> -
> -static int kvm_outl(void *opaque, uint16_t addr, uint32_t data)
> -{
> -cpu_outl(0, addr, data);
> -return 0;
> -}
> -
> int kvm_mmio_read(void *opaque, uint64_t addr, uint8_t *data, int len)
> {
> cpu_physical_memory_rw(addr, data, len, 0);
> @@ -825,14 +776,12 @@ static int handle_io(kvm_vcpu_context_t vcpu)
> struct kvm_run *run = vcpu->run;
> kvm_context_t kvm = vcpu->kvm;
> uint16_t addr = run->io.port;
> - int r;
> int i;
> void *p = (void *)run + run->io.data_offset;
>
> for (i = 0; i < run->io.count; ++i) {
> switch (run->io.direction) {
> case KVM_EXIT_IO_IN:
> - r = 0;
> switch (run->io.size) {
> case 1:
> *(uint8_t *)p = cpu_inb(kvm->opaque, addr);
> @@ -851,16 +800,13 @@ static int handle_io(kvm_vcpu_context_t vcpu)
> case KVM_EXIT_IO_OUT:
> switch (run->io.size) {
> case 1:
> - r = kvm_outb(kvm->opaque, addr,
> - *(uint8_t *)p);
> + cpu_outb(kvm->opaque, addr, *(uint8_t *)p);
> break;
> case 2:
> - r = kvm_outw(kvm->opaque, addr,
> - *(uint16_t *)p);
> + cpu_outw(kvm->opaque, addr, *(uint16_t *)p);
> break;
> case 4:
> - r = kvm_outl(kvm->opaque, addr,
> - *(uint32_t *)p);
> + cpu_outl(kvm->opaque, addr, *(uint32_t *)p);
> break;
> default:
> fprintf(stderr, "bad I/O size %d\n",
> run->io.size);
> --
> 1.6.2.2
>
> --
> 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: [PATCH] Update qemu-kvm to allow a larger BIOS image.
On Thu, 2009-07-16 at 10:57 -0700, Jordan Justen wrote: > On Wed, Jul 15, 2009 at 10:37 PM, Sheng Yang wrote: > > Make sense to me. So what's mattered here is not bios, but qemu-kvm and kvm > > code. The user can replace bios binary by UEFI binary easily, but not with > > kvm > > related part. > > > > I realized you still need separate the qemu-kvm patch into two: one for bios > > and another for qemu. > > Okay, I will split this change apart. > > > And I just hope this modification won't break some old > > OS(any OS got assumption about bios size? I think Tiano team should have > > idea > > on it)... > > I don't think the OS should care about the bios size, but it is > important to update the INT15-E820 memory ranges to help > make sure the OS knows which regions are in use. > > Even without the E820 change, I think it would be unlikely > for an OS to try utilize these memory regions, but it is > definitely better to properly describe it. Hello, I don't know if I get this right, but is it enough to apply this patch to KVM-userspace, or do I also need to have a patched kernel in order to get large images (my image is 4MB) to work in KVM? Thanks, Cristi -- Ing. Cristi Măgherușan, System/Network Engineer Technical University of Cluj-Napoca, Romania http://cc.utcluj.ro +40264 401247 signature.asc Description: This is a digitally signed message part
Re: Any efforts going on concerning virtio Host Drivers for Windows?
On 7/22/2009 9:32 PM, Brian Jackson wrote: On Wednesday 22 July 2009 01:23:56 pm Yaniv Kaul wrote: On 7/22/2009 8:26 PM, Wilken Haase wrote: Hi List, we are already using kvm successfully a while here for our internal Infrastructure. Up to now we're having good results with Linux Guests and are quite happy with kvm. Now it's time to replace some of our current Windows Infrastructure and I'm evaluating Windows 2k3 and 2k8 on KVM vhosts. While virtio does currently successfully boost our Linux Guests I only found network virtio drivers for Windows. These help quiet a bit speeding things but we're well behind our hopes currently. Blockdevice drivers seem to be missing at all. Since I found no evidence of anything evolving here: Are any efforts going on creating or optimizing such drivers ? Can anyone expect seeing something anytime soon ? Yes, efforts are under way to both certify them (get them signed via the MS WHQL process) and optimize them. Soon is the best time estimation I can give, perhaps very soon. Y. What about open sourcing? That too, of course. If anyone can shed some light in this i would be pleased to read your answers. Greetings ! Wilken Haase -- 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: Any efforts going on concerning virtio Host Drivers for Windows?
On Wednesday 22 July 2009 01:23:56 pm Yaniv Kaul wrote: > On 7/22/2009 8:26 PM, Wilken Haase wrote: > > Hi List, > > we are already using kvm successfully a while here for our internal > > Infrastructure. Up to now we're having good results with Linux Guests > > and are quite happy with kvm. > > Now it's time to replace some of our current Windows Infrastructure > > and I'm evaluating Windows 2k3 and 2k8 on KVM vhosts. While virtio > > does currently successfully boost our Linux Guests I only found > > network virtio drivers for Windows. These help quiet a bit speeding > > things but we're well behind our hopes currently. Blockdevice drivers > > seem to be missing at all. > > > > Since I found no evidence of anything evolving here: Are any efforts > > going on creating or optimizing such drivers ? Can anyone expect > > seeing something anytime soon ? > > Yes, efforts are under way to both certify them (get them signed via the > MS WHQL process) and optimize them. Soon is the best time estimation I > can give, perhaps very soon. > Y. What about open sourcing? > > > If anyone can shed some light in this i would be pleased to read your > > answers. > > > > Greetings ! > > Wilken Haase > > -- > 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: Any efforts going on concerning virtio Host Drivers for Windows ?
On 7/22/2009 8:26 PM, Wilken Haase wrote: Hi List, we are already using kvm successfully a while here for our internal Infrastructure. Up to now we're having good results with Linux Guests and are quite happy with kvm. Now it's time to replace some of our current Windows Infrastructure and I'm evaluating Windows 2k3 and 2k8 on KVM vhosts. While virtio does currently successfully boost our Linux Guests I only found network virtio drivers for Windows. These help quiet a bit speeding things but we're well behind our hopes currently. Blockdevice drivers seem to be missing at all. Since I found no evidence of anything evolving here: Are any efforts going on creating or optimizing such drivers ? Can anyone expect seeing something anytime soon ? Yes, efforts are under way to both certify them (get them signed via the MS WHQL process) and optimize them. Soon is the best time estimation I can give, perhaps very soon. Y. If anyone can shed some light in this i would be pleased to read your answers. Greetings ! Wilken Haase -- 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
Any efforts going on concerning virtio Host Drivers for Windows ?
Hi List, we are already using kvm successfully a while here for our internal Infrastructure. Up to now we're having good results with Linux Guests and are quite happy with kvm. Now it's time to replace some of our current Windows Infrastructure and I'm evaluating Windows 2k3 and 2k8 on KVM vhosts. While virtio does currently successfully boost our Linux Guests I only found network virtio drivers for Windows. These help quiet a bit speeding things but we're well behind our hopes currently. Blockdevice drivers seem to be missing at all. Since I found no evidence of anything evolving here: Are any efforts going on creating or optimizing such drivers ? Can anyone expect seeing something anytime soon ? If anyone can shed some light in this i would be pleased to read your answers. Greetings ! Wilken Haase -- 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 2/2] qemu-kvm: broken MSI routing work-around
Kernels up to 2.6.31 have a bug: MSI entries where looked at when irq
is acked, address_lo was interpreted as irqchip, and
address_hi as pin. If that matches a real interrupt this prevents
ack notifier from being processed.
Since these kernels ignore the value for address_hi when delivering
MSI, work around this by setting a value that never matches an
interrupt pin number.
Pointers to relevant kernel code, for reference: in kernel v2.6.31-rc3:
kvm_notify_acked_irq - fails to check irq type,
kvm_set_msi - ignored address_hi in message
Signed-off-by: Michael S. Tsirkin
---
qemu-kvm.c | 32 ++--
1 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/qemu-kvm.c b/qemu-kvm.c
index cebaa65..ec6d583 100644
--- a/qemu-kvm.c
+++ b/qemu-kvm.c
@@ -38,6 +38,32 @@
#error libkvm: userspace and kernel version mismatch
#endif
+#ifdef KVM_CAP_IRQ_ROUTING
+/* Broken MSI routing work-around:
+ * Kernels up to 2.6.31 have a bug: MSI entries where looked at when irq
+ * is acked, address_lo was interpreted as irqchip, and
+ * address_hi as pin. If that matches a real interrupt this prevents
+ * ack notifier from being processed.
+ *
+ * Since these kernels ignore the value for address_hi when delivering
+ * MSI, work around this by setting a value that never matches an
+ * interrupt pin number.
+ */
+#define KVM_BROKEN_MSI_ROUTING 1
+static inline
+void kvm_broken_msi_fix(struct kvm_irq_routing_entry *entry)
+{
+ if (entry->type == KVM_IRQ_ROUTING_MSI) {
+ entry->u.msi.address_hi = 0x;
+ }
+}
+static inline
+unsigned kvm_broken_msi_address_hi(struct kvm_irq_routing_entry *entry)
+{
+ return 0x;
+}
+#endif
+
int kvm_allowed = 1;
int kvm_irqchip = 1;
int kvm_pit = 1;
@@ -1433,6 +1459,7 @@ int kvm_add_routing_entry(kvm_context_t kvm,
new->type = entry->type;
new->flags = entry->flags;
new->u = entry->u;
+ kvm_broken_msi_fix(new);
set_gsi(kvm, entry->gsi);
@@ -1489,7 +1516,7 @@ int kvm_del_routing_entry(kvm_context_t kvm,
if (e->u.msi.address_lo ==
entry->u.msi.address_lo
&& e->u.msi.address_hi ==
- entry->u.msi.address_hi
+ kvm_broken_msi_address_hi(entry)
&& e->u.msi.data == entry->u.msi.data) {
p = &kvm->irq_routes->
entries[--kvm->irq_routes->nr];
@@ -1550,9 +1577,10 @@ int kvm_update_routing_entry(kvm_context_t kvm,
break;
case KVM_IRQ_ROUTING_MSI:
if (e->u.msi.address_lo == entry->u.msi.address_lo &&
-e->u.msi.address_hi == entry->u.msi.address_hi &&
+e->u.msi.address_hi == kvm_broken_msi_address_hi(entry) &&
e->u.msi.data == entry->u.msi.data) {
memcpy(&e->u.msi, &newentry->u.msi, sizeof e->u.msi);
+ kvm_broken_msi_fix(e);
return 0;
}
break;
--
1.6.2.5
--
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 1/2] qemu-kvm: msix table update thinko fix
When updating msi irq routing entries, we should memcpy the new entry
over the old one. Current code gets it wrong, and only works because
it's uncommon for guests to change MSI tables.
Signed-off-by: Michael S. Tsirkin
---
qemu-kvm.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/qemu-kvm.c b/qemu-kvm.c
index 60e5eac..cebaa65 100644
--- a/qemu-kvm.c
+++ b/qemu-kvm.c
@@ -1552,7 +1552,7 @@ int kvm_update_routing_entry(kvm_context_t kvm,
if (e->u.msi.address_lo == entry->u.msi.address_lo &&
e->u.msi.address_hi == entry->u.msi.address_hi &&
e->u.msi.data == entry->u.msi.data) {
-memcpy(&e->u.msi, &entry->u.msi, sizeof e->u.msi);
+memcpy(&e->u.msi, &newentry->u.msi, sizeof e->u.msi);
return 0;
}
break;
--
1.6.2.5
--
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 0/2] qemu-kvm: misc msix fixes
Here are two bug-fixes for MSI-X support in qemu-kvm. I bundled them together because the touch the same code. Michael S. Tsirkin (2): qemu-kvm: msix table update thinko fix qemu-kvm: broken MSI routing work-around qemu-kvm.c | 34 +++--- 1 files changed, 31 insertions(+), 3 deletions(-) -- 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] fix serious regression
Glauber Costa wrote: Today I found a very catastrophic regression: I cannot run my mission critical servers running RHL7.1 anymore. This is a total disaster. Fortunately, I was able to isolate the commit that caused it: commit bb598da496c040d42dde564bd8ace181be52293e Author: Glauber Costa Date: Mon Jul 6 16:12:52 2009 -0400 This guy is certainly stupid, and deserves punishment. It means I'll be writting code using emacs for the next week. Marcelo, please apply Signed-off-by: Glauber Costa Does this mean the goofy MMIO thing isn't strictly needed? Regards, Anthony Liguori -- 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-88 broke floppy controller
- "Gleb Natapov" wrote: > On Wed, Jul 22, 2009 at 07:43:51AM -0400, Alexey Eromenko wrote: > > > > Hi All ! > > > > I found a new bug in Floppy controller -- usually I report bugs to > Avi, > > but since he is not here, I decided to report to mailing list. > > > > This bugs prevents Windows booting with Floppy inserted. > > > > Qemu command to reproduce: > > ./qemu-kvm -fda myfloppy.vfd -cdrom > /isos/windows/Windows2003_r2_VLK.iso -boot d > > > > It won't boot from CD-ROM (black screen), and will stuck during > booting from hard disk. > > It affects both Intel & AMD systems, but not Qemu emulator. (-no-kvm > works) > > > > I did bisect and found bug in KVM userspace git: > > > > kvm-87-239-gbb598da ( commit > bb598da496c040d42dde564bd8ace181be52293e by Glauber Costa) > > on 6.7.2009. > > > > Can you look at it please ? > > > Can you try this patch? > http://patchwork.kernel.org/patch/36661/ > Thanks Gleb ! This indeed fixed my problem ! -Alexey -- 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-88 broke floppy controller
On Wed, Jul 22, 2009 at 07:43:51AM -0400, Alexey Eromenko wrote: > > Hi All ! > > I found a new bug in Floppy controller -- usually I report bugs to Avi, > but since he is not here, I decided to report to mailing list. > > This bugs prevents Windows booting with Floppy inserted. > > Qemu command to reproduce: > ./qemu-kvm -fda myfloppy.vfd -cdrom /isos/windows/Windows2003_r2_VLK.iso > -boot d > > It won't boot from CD-ROM (black screen), and will stuck during booting from > hard disk. > It affects both Intel & AMD systems, but not Qemu emulator. (-no-kvm works) > > I did bisect and found bug in KVM userspace git: > > kvm-87-239-gbb598da ( commit bb598da496c040d42dde564bd8ace181be52293e by > Glauber Costa) > on 6.7.2009. > > Can you look at it please ? > Can you try this patch? http://patchwork.kernel.org/patch/36661/ -- Gleb. -- 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-88 broke floppy controller
Hi All ! I found a new bug in Floppy controller -- usually I report bugs to Avi, but since he is not here, I decided to report to mailing list. This bugs prevents Windows booting with Floppy inserted. Qemu command to reproduce: ./qemu-kvm -fda myfloppy.vfd -cdrom /isos/windows/Windows2003_r2_VLK.iso -boot d It won't boot from CD-ROM (black screen), and will stuck during booting from hard disk. It affects both Intel & AMD systems, but not Qemu emulator. (-no-kvm works) I did bisect and found bug in KVM userspace git: kvm-87-239-gbb598da ( commit bb598da496c040d42dde564bd8ace181be52293e by Glauber Costa) on 6.7.2009. Can you look at it please ? -Alexey Eromenko -- 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: VGA address mapping?
On 22.07.2009, at 09:48, Gleb Natapov wrote: On Tue, Jul 21, 2009 at 04:06:10PM -0700, Saksena, Abhishek wrote: Would also like to mention I am not using Qemu and building some basic IO models around KVM (only using libkvm.h) -Abhishek From: Saksena, Abhishek Sent: Tuesday, July 21, 2009 11:13 AM To: kvm@vger.kernel.org Subject: VGA address mapping? Hi I am implementing a VGA Device model. The model provides functions to read/write VGA memory space. Just for testing I want to capture memory reads/writes to addresses 0xA->0xC and forward it to my VGA model. I have used following function to create physical ram int kvm_create ( kvm_context_t> kvm, unsigned long phys_mem_bytes, void ** phys_mem ) The function comments says that this creates a new virtual machine, maps physical RAM to it, and creates a virtual CPU for it. Memory gets mapped for addresses 0->0xA, 0xC->phys_mem_bytes. This indeed what comment says, but looking at the code I don't see it using phys_mem_bytes/phys_mem parameters at all. I'm not sure about libkvm, but the real KVM logic is "memory is not mapped -> MMIO". So if you just don't map it, you should get MMIO exits on that range. Keep in mind that there are people out there trying to get rid of libkvm :-) Alex -- 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: VGA address mapping?
On Tue, Jul 21, 2009 at 04:06:10PM -0700, Saksena, Abhishek wrote: > Would also like to mention I am not using Qemu and building some basic IO > models around KVM (only using libkvm.h) > > -Abhishek > > From: Saksena, Abhishek > Sent: Tuesday, July 21, 2009 11:13 AM > To: kvm@vger.kernel.org > Subject: VGA address mapping? > > Hi > I am implementing a VGA Device model. The model provides functions to > read/write VGA memory space. > > Just for testing I want to capture memory reads/writes to addresses > 0xA->0xC and forward it to my VGA model. > > > I have used following function to create physical ram > > int kvm_create ( > kvm_context_t >kvm, > unsigned long phys_mem_bytes, > void ** phys_mem > ) > > The function comments says that this creates a new virtual machine, maps > physical RAM to it, and creates a virtual CPU for it. Memory gets mapped for > addresses 0->0xA, 0xC->phys_mem_bytes. > This indeed what comment says, but looking at the code I don't see it using phys_mem_bytes/phys_mem parameters at all. Look at QEMU code how memory is created. > > > I was expecting mimio read/write callbacks to capture transactions between > 0xA->0xC but I don't see that happening. > > > > My question is how I can configure KVM to forward me reads/writes for VGA > address space? > > > > > > Thanks > > Abhishek > -- > 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 -- Gleb. -- 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
