Plan 9 install problems

Plan 9 install problems

[James Morris]

I just tried installing Plan 9 from the current CD ISO (see 
http://plan9.bell-labs.com/plan9/download.html) under KVM and didn't get 
very far.

It boots, then hangs after some initialization.  Screenshot of the guest 
at this point: http://namei.org/images/p9-kvm.png

On the host, the startup messages look like:

set_vram_mapping: memory: e0000000 - e0800000
set_vram_mapping: return 0x2b03ced87000
vga_update_vram: base 0x2b03ced87000 ptr 0x2b03ce585010
vga_update_vram: done

kernel: kvm: unhandled rdmsr: 1


When the guest hangs, the host starts logging this repeatedly: 

kernel: double fault 0x80031b30 @ 0xf01003c9

This is with the 2.6.20-rc1 kernel and kvm-6 userland.

Seems to work as expected with the kvm kernel module unloaded (i.e. plain 
qemu).



- James
-- 
James Morris
<jmorris-gx6/JNMH7DfYtjvyW6yDsg@public.gmane.org>

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Plan 9 install problems

[Avi Kivity]

James Morris wrote:
> I just tried installing Plan 9 from the current CD ISO (see 
> http://plan9.bell-labs.com/plan9/download.html) under KVM and didn't get 
> very far.
>
> It boots, then hangs after some initialization.  Screenshot of the guest 
> at this point: http://namei.org/images/p9-kvm.png
>
> On the host, the startup messages look like:
>
> set_vram_mapping: memory: e0000000 - e0800000
> set_vram_mapping: return 0x2b03ced87000
> vga_update_vram: base 0x2b03ced87000 ptr 0x2b03ce585010
> vga_update_vram: done
>
> kernel: kvm: unhandled rdmsr: 1
>
>   

This is an old Penium msr related to machine checks.

> When the guest hangs, the host starts logging this repeatedly: 
>
> kernel: double fault 0x80031b30 @ 0xf01003c9
>   

Since we don't handle the rdmsr, we inject a general protection fault.  
The guest isn't ready to handle this, so we inject a double fault.  The 
guest isn't ready to handle a double fault either -- at this point we 
should triple fault but we don't.

> This is with the 2.6.20-rc1 kernel and kvm-6 userland.
>
> Seems to work as expected with the kvm kernel module unloaded (i.e. plain 
> qemu).
>   

The way to fix is to add handling to {svm,vmx}_get_msr() for msr 1 (and 
any other pointless msrs the guest reads or writes).  From a cursory 
reading of the machine check docs, returning 0 should be fine for msr 1.

[those common msrs should really be moved to kvm_main.c one day]

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


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Plan 9 install problems

[Michael Riepe]

Hi!

Avi Kivity wrote:

> The way to fix is to add handling to {svm,vmx}_get_msr() for msr 1 (and 
> any other pointless msrs the guest reads or writes).  From a cursory 
> reading of the machine check docs, returning 0 should be fine for msr 1.

Yep.

But that doesn't help with Plan9 (just checked it). The installer fails
at VM entry later because it tries to use a "big" code segment (limit =
0xffffffff). The same is true for OpenSolaris (cs limit = 0xfffff), by
the way.

-- 
Michael "Tired" Riepe <michael-0QoEqw4nQxo@public.gmane.org>
X-Tired: Each morning I get up I die a little

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Plan 9 install problems

[Avi Kivity]

Michael Riepe wrote:
> Hi!
>
> Avi Kivity wrote:
>
>   
>> The way to fix is to add handling to {svm,vmx}_get_msr() for msr 1 (and 
>> any other pointless msrs the guest reads or writes).  From a cursory 
>> reading of the machine check docs, returning 0 should be fine for msr 1.
>>     
>
> Yep.
>
> But that doesn't help with Plan9 (just checked it). The installer fails
> at VM entry later because it tries to use a "big" code segment (limit =
> 0xffffffff). The same is true for OpenSolaris (cs limit = 0xfffff), by
> the way.
>   

Okay.  Can someone with an AMD machine test these two OSes?  There 
shouldn't be any problems with real mode there.

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


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Linux - KVM - MAC OS X

[sean-cz32UWRuVxBIf6P1QZMOBw]

Shalom Avi,

are there any plans to have MAC OS X running under KVM??

I have KVM running under Edgy.


TIA and regards


John


John Cassidy (Dipl.-Ingr.)

Berninastrasse 9

8057 Zuerich

Europe

Telephone: +41 (0) 43 300 4602

Mobile:    +41 (0) 79 207 3268


E-Mail: john.cassidy-+vc80D69rgWBubSflsco8w@public.gmane.org

http://www.JDCassidy.net

http://www.europeunited.org

http://en.wikipedia.org/wiki/Europe_United







-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Linux - KVM - MAC OS X

[Avi Kivity]

sean-cz32UWRuVxBIf6P1QZMOBw@public.gmane.org wrote:
> Shalom Avi,
>
> are there any plans to have MAC OS X running under KVM??
>
> I have KVM running under Edgy.
>
>   

I think that Mac OS X requires different firmware than that provided by 
the qemu bios which we use.

If you can run Mac OS X under regular qemu, then kvm should work too.


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


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Plan 9 install problems

[Michael Riepe]

[-- Attachment #1: Type: text/plain, Size: 1330 bytes --]

Hi there!

Avi Kivity wrote:
> Michael Riepe wrote:
> 
>> Hi!
>>
>> Avi Kivity wrote:
>>
>>  
>>
>>> The way to fix is to add handling to {svm,vmx}_get_msr() for msr 1
>>> (and any other pointless msrs the guest reads or writes).  From a
>>> cursory reading of the machine check docs, returning 0 should be fine
>>> for msr 1.

Done, see mce-handling.patch. The AMD part is not tested yet (I don't
have access to an SVM capable machine).

>> Yep.
>>
>> But that doesn't help with Plan9 (just checked it). The installer fails
>> at VM entry later because it tries to use a "big" code segment (limit =
>> 0xffffffff). The same is true for OpenSolaris (cs limit = 0xfffff), by
>> the way.
>>   
> 
> 
> Okay.  Can someone with an AMD machine test these two OSes?  There
> shouldn't be any problems with real mode there.

OpenSolaris runs on Intel with a simple modification: force the CS limit
to 0xffff in real mode (I wonder why that didn't happen already).

Plan9, on the other hand, seems to execute code outside the 64K range.
With cs-limit.patch, it dies at RIP 0x100212. I'm afraid we will need a
full-blown real mode instruction emulator to handle that.

Please apply cs-limit.patch first in order to avoid fuzz.

-- 
Michael "Tired" Riepe <michael-0QoEqw4nQxo@public.gmane.org>
X-Tired: Each morning I get up I die a little

[-- Attachment #2: cs-limit.patch --]
[-- Type: text/plain, Size: 462 bytes --]

Signed-off-by: Michael Riepe <michael-0QoEqw4nQxo@public.gmane.org>

Index: vmx.c
===================================================================
--- vmx.c	(revision 4118)
+++ vmx.c	(working copy)
@@ -726,6 +726,7 @@
 	vmcs_write32(GUEST_SS_AR_BYTES, 0xf3);
 
 	vmcs_write32(GUEST_CS_AR_BYTES, 0xf3);
+	vmcs_write32(GUEST_CS_LIMIT, 0xffff);
 	vmcs_write16(GUEST_CS_SELECTOR, vmcs_readl(GUEST_CS_BASE) >> 4);
 
 	fix_rmode_seg(VCPU_SREG_ES, &vcpu->rmode.es);

[-- Attachment #3: mce-handling.patch --]
[-- Type: text/plain, Size: 819 bytes --]

Signed-off-by: Michael Riepe <michael-0QoEqw4nQxo@public.gmane.org>
 
Index: svm.c
===================================================================
--- svm.c	(revision 4117)
+++ svm.c	(working copy)
@@ -1073,6 +1073,8 @@
 static int svm_get_msr(struct kvm_vcpu *vcpu, unsigned ecx, u64 *data)
 {
 	switch (ecx) {
+	case MSR_IA32_P5_MC_ADDR:
+	case MSR_IA32_P5_MC_TYPE:
 	case MSR_IA32_MC0_CTL:
 	case MSR_IA32_MCG_STATUS:
 	case MSR_IA32_MCG_CAP:
Index: vmx.c
===================================================================
--- vmx.c	(revision 4117)
+++ vmx.c	(working copy)
@@ -359,6 +359,8 @@
 	case MSR_IA32_SYSENTER_ESP:
 		data = vmcs_read32(GUEST_SYSENTER_ESP);
 		break;
+	case MSR_IA32_P5_MC_ADDR:
+	case MSR_IA32_P5_MC_TYPE:
 	case MSR_IA32_MC0_CTL:
 	case MSR_IA32_MCG_STATUS:
 	case MSR_IA32_MCG_CAP:

[-- Attachment #4: Type: text/plain, Size: 347 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #5: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: Plan 9 install problems

[Avi Kivity]

Michael Riepe wrote:
> OpenSolaris runs on Intel with a simple modification: force the CS limit
> to 0xffff in real mode (I wonder why that didn't happen already).
>
> Plan9, on the other hand, seems to execute code outside the 64K range.
> With cs-limit.patch, it dies at RIP 0x100212. I'm afraid we will need a
> full-blown real mode instruction emulator to handle that.
>
> Please apply cs-limit.patch first in order to avoid fuzz.
>   

Both patches applied.  Thanks!

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


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV