|
|
|
|
|
|
|
|
|
|
xen-devel
RE: [Xen-devel] ACPI suspend/resume on Dell Inspirons 1464/1564/1764
In case this helps, here is our newly updated patch that doesn't modify the global variables. I have tested it on a Dell 1764 which has the i5 chips.
diff -r 6b2b1470f009 xen-3.4.2/xen/arch/x86/hvm/vmx/vmcs.c
--- a/xen-3.4.2/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen-3.4.2/xen/arch/x86/hvm/vmx/vmcs.c
@@ -515,6 +515,8 @@
struct domain *d = v->domain;
uint16_t sysenter_cs;
unsigned long sysenter_eip;
+ u32 _vmx_vmexit_control;
+ u32 _vmx_vmentry_control;
vmx_vmcs_enter(v);
@@ -524,6 +526,9 @@
v->arch.hvm_vmx.exec_control = vmx_cpu_based_exec_control;
v->arch.hvm_vmx.secondary_exec_control = vmx_secondary_exec_control;
+ _vmx_vmexit_control = vmx_vmexit_control;
+ _vmx_vmentry_control = vmx_vmentry_control;
+
if ( paging_mode_hap(d) )
{
v->arch.hvm_vmx.exec_control &= ~(CPU_BASED_INVLPG_EXITING |
@@ -533,17 +538,17 @@
else
{
v->arch.hvm_vmx.secondary_exec_control &= ~SECONDARY_EXEC_ENABLE_EPT;
- vmx_vmexit_control &= ~(VM_EXIT_SAVE_GUEST_PAT |
+ _vmx_vmexit_control &= ~(VM_EXIT_SAVE_GUEST_PAT |
VM_EXIT_LOAD_HOST_PAT);
- vmx_vmentry_control &= ~VM_ENTRY_LOAD_GUEST_PAT;
+ _vmx_vmentry_control &= ~VM_ENTRY_LOAD_GUEST_PAT;
}
/* Do not enable Monitor Trap Flag unless start single step debug */
v->arch.hvm_vmx.exec_control &= ~CPU_BASED_MONITOR_TRAP_FLAG;
__vmwrite(CPU_BASED_VM_EXEC_CONTROL, v->arch.hvm_vmx.exec_control);
- __vmwrite(VM_EXIT_CONTROLS, vmx_vmexit_control);
- __vmwrite(VM_ENTRY_CONTROLS, vmx_vmentry_control);
+ __vmwrite(VM_EXIT_CONTROLS, _vmx_vmexit_control);
+ __vmwrite(VM_ENTRY_CONTROLS, _vmx_vmentry_control);
if ( cpu_has_vmx_secondary_exec_control )
__vmwrite(SECONDARY_VM_EXEC_CONTROL,
-----Original Message-----
From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx on behalf of Roger Cruz
Sent: Wed 5/19/2010 3:41 PM
To: Keir Fraser; xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [Xen-devel] ACPI suspend/resume on Dell Inspirons 1464/1564/1764
OK. My patch attempted to preserve the changes across the global variables as that is what I thought the intent was. If I understood you right, the changes in construct_vmcs don't need to apply to future vmcs creations so the changes may only be done locally.
When do you think an official patch will be available?
Thank you.
Roger
-----Original Message-----
From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
Sent: Wed 5/19/2010 3:24 PM
To: Roger Cruz; xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] ACPI suspend/resume on Dell Inspirons 1464/1564/1764
On 19/05/2010 17:36, "Roger Cruz" <roger.cruz@xxxxxxxxxxxxxxxxxxx> wrote:
> else
> {
> v->arch.hvm_vmx.secondary_exec_control &= ~SECONDARY_EXEC_ENABLE_EPT;
> vmx_vmexit_control &= ~(VM_EXIT_SAVE_GUEST_PAT |
> VM_EXIT_LOAD_HOST_PAT);
> vmx_vmentry_control &= ~VM_ENTRY_LOAD_GUEST_PAT;
> }
This is the bug. construct_vmcs() should make local copies of
vmx_vmexit_control and vmx_vmentry_control, and only clear bits in those
local copies. It should then __vmwrite() those local copies. I will make a
patch and apply to xen-unstable and xen-4.0 and xen-3.4.
Thanks,
Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|