okhan | 1 Feb 2007 01:26
Picon

paravirtualization hypercall API

hi,

   Is there any documentation/information on the paravirtualization hypercall API for the KVM
paravirtualization for Linux announced by Ingo Molnar?

Omar Khan

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
Jeff Chua | 1 Feb 2007 03:52
Picon

Re: [PATCH] KVM: Fix lockup on 32-bit intel hosts with nx disabled in the bios

On 1/31/07, Avi Kivity <avi@...> wrote:
> Intel hosts, without long mode, and with nx support disabled in the bios
> have an efer that is readable but not writable.  This causes a lockup on
> switch to guest mode (even though it should exit with reason 34 according to
> the documentation).

Avi, thank you for the patch. I can confirm that this patch works on
my IBM X60s notebook. Without it, the whole PC locks up upon starting
qemu.

Thanks,
Jeff.

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
Avi Kivity | 1 Feb 2007 06:24

Re: paravirtualization hypercall API

okhan@... wrote:
> hi,
>
>    Is there any documentation/information on the paravirtualization hypercall API for the KVM
paravirtualization for Linux announced by Ingo Molnar?
>
>   

It's documented in the source, which will be merged in a couple of days.

--

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
Ingo Molnar | 1 Feb 2007 08:55
Picon
Picon
Favicon

Re: [PATCH] KVM: Fix lockup on 32-bit intel hosts with nx disabled in the bios


* Avi Kivity <avi@...> wrote:

> Intel hosts, without long mode, and with nx support disabled in the 
> bios have an efer that is readable but not writable.  This causes a 
> lockup on switch to guest mode (even though it should exit with reason 
> 34 according to the documentation).
> 
> Signed-off-by: Avi Kivity <avi@...>

i think this is for v2.6.20. I have tested this ontop of -rc7.

Acked-by: Ingo Molnar <mingo@...>

	Ingo

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
Avi Kivity | 1 Feb 2007 09:09

Re: [RFT] kvm host suspend/resume

Jeremy Katz wrote:
> Avi Kivity wrote:
>> Jeremy Katz wrote:
>>> On Wed, 2007-01-31 at 12:32 +0200, Avi Kivity wrote: 
>>>> Jeremy Katz wrote:
>>>>> Avi Kivity wrote:
>>>>>> I've committed kvm support for host suspend-to-disk (and 
>>>>>> hopefully resume too).  This means you can suspend your machine 
>>>>>> with running vms, and resume it later will all vms returning to 
>>>>>> the saved state.  This should please laptop owners.
>>>>>>         
>>>>> So testing with trunk (r4365) + 2.6.20-rc5-ish, I'm able to 
>>>>> suspend and resume with the modules loaded.  Starting a guest 
>>>>> after resume gets the following oops in the host; guest is in the 
>>>>> grub menu at that point.
>>>>>       
>>>> 2.6.20-rc6 can't suspend my test machine (regardless of kvm), so 
>>>> this possible fix is completely untested.
>>>
>>> Failure looks basically the same.  Will try to do some more
>>> investigation later today.
>>
>> Looks like ->hardware_enable() was not called for some reason.  
>> Sprinkling printks in the cpu hotplug and resume callbacks will help.
>
> Multiple things failing here together.
>
> 1) With the versioning of Fedora kernels, things were falling back to 
> the compat version of smp_call_function_single which then doesn't seem 
> to work properly (->hardware_disable() and ->hardware_enable() never 
(Continue reading)

Avi Kivity | 1 Feb 2007 09:25

Re: [PATCH try #2] kvm-12 userland guest reboot fix

Joerg Roedel wrote:
> From: Markus Rechberger <markus.rechberger@...>
> From: Joerg Roedel <joerg.roedel@...>
>
> This patch fixes the initialization of the segment registers which
> solves the triple fault and keyboard controller reset problems in
> kvm/qemu guests as well as the slow grub menu interaction. The patch
> should also work on Intel VMX now.
>   
> diff -upr kvm-12/qemu/target-i386/helper2.c kvm-12-reboot-fixed/qemu/target-i386/helper2.c
> --- kvm-12/qemu/target-i386/helper2.c	2006-12-31 14:31:38.000000000 +0100
> +++ kvm-12-reboot-fixed/qemu/target-i386/helper2.c	2007-01-23 20:24:42.265987000 +0100
>  <at>  <at>  -151,6 +151,9  <at>  <at>  CPUX86State *cpu_x86_init(void)
>  void cpu_reset(CPUX86State *env)
>  {
>      int i;
> +    unsigned int flags = DESC_P_MASK |
> +                         DESC_S_MASK |
> +                         (2 << DESC_TYPE_SHIFT);
>  
>      memset(env, 0, offsetof(CPUX86State, breakpoints));
>  
>  <at>  <at>  -173,9 +176,9  <at>  <at>  void cpu_reset(CPUX86State *env)
>      env->tr.flags = DESC_P_MASK;
>      
>      cpu_x86_load_seg_cache(env, R_CS, 0xf000, 0xffff0000, 0xffff, 0); 
> -    cpu_x86_load_seg_cache(env, R_DS, 0, 0, 0xffff, 0);
> -    cpu_x86_load_seg_cache(env, R_ES, 0, 0, 0xffff, 0);
> -    cpu_x86_load_seg_cache(env, R_SS, 0, 0, 0xffff, 0);
> +    cpu_x86_load_seg_cache(env, R_DS, 0, 0, 0xffff, flags);
(Continue reading)

Daniel Hecken | 1 Feb 2007 10:07
Picon

Re: [PATCH try #2] kvm-12 userland guest reboot fix

Avi Kivity schrieb:
> Joerg Roedel wrote:
>> From: Markus Rechberger <markus.rechberger@...>
>> From: Joerg Roedel <joerg.roedel@...>
>>
>> This patch fixes the initialization of the segment registers which
>> solves the triple fault and keyboard controller reset problems in
>> kvm/qemu guests as well as the slow grub menu interaction. The patch
>> should also work on Intel VMX now.
>>   
>> diff -upr kvm-12/qemu/target-i386/helper2.c kvm-12-reboot-fixed/qemu/target-i386/helper2.c
>> --- kvm-12/qemu/target-i386/helper2.c	2006-12-31 14:31:38.000000000 +0100
>> +++ kvm-12-reboot-fixed/qemu/target-i386/helper2.c	2007-01-23 20:24:42.265987000 +0100
>>  <at>  <at>  -151,6 +151,9  <at>  <at>  CPUX86State *cpu_x86_init(void)
>>  void cpu_reset(CPUX86State *env)
>>  {
>>      int i;
>> +    unsigned int flags = DESC_P_MASK |
>> +                         DESC_S_MASK |
>> +                         (2 << DESC_TYPE_SHIFT);
>>  
>>      memset(env, 0, offsetof(CPUX86State, breakpoints));
>>  
>>  <at>  <at>  -173,9 +176,9  <at>  <at>  void cpu_reset(CPUX86State *env)
>>      env->tr.flags = DESC_P_MASK;
>>      
>>      cpu_x86_load_seg_cache(env, R_CS, 0xf000, 0xffff0000, 0xffff, 0); 
>> -    cpu_x86_load_seg_cache(env, R_DS, 0, 0, 0xffff, 0);
>> -    cpu_x86_load_seg_cache(env, R_ES, 0, 0, 0xffff, 0);
>> -    cpu_x86_load_seg_cache(env, R_SS, 0, 0, 0xffff, 0);
(Continue reading)

Avi Kivity | 1 Feb 2007 10:37

Re: [PATCH try #2] kvm-12 userland guest reboot fix

Daniel Hecken wrote:
> I tried this patch yesterday whilst installing Windows 2003 with kvm svn
>  and when the installer requested a reboot I just got this in the console:
>
> unhandled vm exit:  0x80000021
> rax 0000000000000000 rbx 0000000000000000 rcx 0000000000000000 rdx
> 0000000000000600
> rsi 0000000000000000 rdi 0000000000000000 rsp 0000000000000000 rbp
> 0000000000000000
> r8  0d7905c600010000 r9  b7f506e0b7f4fff4 r10 bf9d7c3008049138 r11
> b7f50898b7f42e42
> r12 00000001b7bbf020 r13 0000000000000001 r14 000000920804a0a2 r15
> 0812335c00000000
> rip 000000000000fff0 rflags 00023002
>
> My host is a Fujitsu-Siemens S7110 with Intel Core 2 Duo with Ubuntu
> Feisty kernel 2.6.20 and the svn revision was 4368.
>   

You're running on an Intel host, and it looks like the patch only fixes 
things for amd (I plan to apply it as it doesn't cause any regressions, 
though).

--

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

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
(Continue reading)

Gregory Haskins | 1 Feb 2007 13:33
Picon
Favicon
Gravatar

SIGILL in grub in guest on 4365


Hi All,
  New to the list and project...hoping to make a meaningful contribution here someday :)

I am in the process of coming up to speed on the KVM project (very cool BTW).  I found that it was extremely
simple to get setup and running.  During the course of setting it up, I found an issue running a SUSE Linux
Enterprise Desktop 10 (x86_64) guest.  Basically, if you try to run GRUB, the grub process dies
immediately as it takes an illegal instruction (SIGILL) signal.  Non-symbol stack traces indicate it was
in the sync() call in libc.  I have worked around this temporarily by installing LILO under rescue
mode...but I figured what better way to learn the code than to try to debug and fix this issue.

My assumption is that an illegal-opcode will cause either a vm-exit or an illegal-opcode exception down to
the host.  This in turn would cause either the KVM_RUN ioctl to return (presumably with an EXCEPTION
reason) or a signal to be delivered to QEMU.  Problem is, I am fairly stumped at this point trying to prove
this is true.

So my questions are: 

1) Is this how illegal-op would be handled, or would that stay entirely in the domain of the guest?  

2) If they do cause a host exception/exit, what is that path that would handle this?

I put breakpoints in QEMU in all the obvious places (e.g. looking for VM-Exits in kvm_run(), host-2-guest
exception generation points, and/or signal handlers).  I have also straced QEMU and it doesn't appear to
be taking any signals other than SIGIO.  My next step will be to start sprinkling printfs in the QEMU/KVM
code and/or debugging/LTT'ing the kernel, but I figured I would ping the group for suggestions first.  Any
pointers out there?

Another possibility is that the guest is not generating a real illegal-op and the bug is that QEMU/KVM is
accidentally injecting the exception condition (due to corruption, etc) and that explains why I cant
(Continue reading)

Avi Kivity | 1 Feb 2007 13:46

Re: SIGILL in grub in guest on 4365

Gregory Haskins wrote:
> Hi All,
>   New to the list and project...hoping to make a meaningful contribution here someday :)
>
> I am in the process of coming up to speed on the KVM project (very cool BTW).  I found that it was extremely
simple to get setup and running.  During the course of setting it up, I found an issue running a SUSE Linux
Enterprise Desktop 10 (x86_64) guest.  Basically, if you try to run GRUB, the grub process dies
immediately as it takes an illegal instruction (SIGILL) signal.  Non-symbol stack traces indicate it was
in the sync() call in libc.  I have worked around this temporarily by installing LILO under rescue
mode...but I figured what better way to learn the code than to try to debug and fix this issue.
>
> My assumption is that an illegal-opcode will cause either a vm-exit or an illegal-opcode exception down
to the host.  This in turn would cause either the KVM_RUN ioctl to return (presumably with an EXCEPTION
reason) or a signal to be delivered to QEMU.  Problem is, I am fairly stumped at this point trying to prove
this is true.
>   

Well, you can't prove it's true, since it's false :)

> So my questions are: 
>
> 1) Is this how illegal-op would be handled, or would that stay entirely in the domain of the guest?  
>   

An illegal opcode in the guest is handled normally by generating #UD in 
the guest, without host involvement at all.

> 2) If they do cause a host exception/exit, what is that path that would handle this?
>
> I put breakpoints in QEMU in all the obvious places (e.g. looking for VM-Exits in kvm_run(), host-2-guest
(Continue reading)


Gmane