[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 20 of 20] n2 MSR handling and capability exposure



Hi, 

At 09:15 +0200 on 26 Jul (1311671730), Jeroen Groenewegen van der Weyden wrote:
> I think the behaviour is still the same,
> 
> 1) cs23726
> 2) vvmc.c patched with attachment.
> 3) new compile
> 
> after a little while the domu becomes ir-responsive.

Dang. :(

> with xm dmesg I see a lot of these:
> (XEN) vvmx.c:1182:d3 vmclear gpa 1f5a89000 not the same as current
> vmcs 00000001f448f000
> (XEN) vvmx.c:1182:d3 vmclear gpa 1f5a89000 not the same as current
> vmcs 00000001f448f000

Yeah; with the patch applied, those should be harmlesss.

If you give your first-level guest only one vcpu, does the problem go
away?

> Note: I have to say, patching this on this level is not common
> practice for me. although I think I did it the right way. please
> keep in mind I can make mistakes on this level.

If you want to double-check that you've done the patch right,
edit xen/arch/x86/hvm/vmx/vvmx.c, and at line 1185, just under the line
` /* Even if this VMCS isn't the current one, we must clear it. */ '
add a line ` printk("boo!\n"); '.  Then when you recompile and test you
should see "boo!" printed just after each "vvmx.c:1182:d3" line on the
console.

Cheers,

Tim.

-- 
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, Xen Platform Team
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.