From mboxrd@z Thu Jan 1 00:00:00 1970 From: Shriram Rajagopalan Subject: Re: xl/xm save -c fails - set_vcpucontext EOPNOTSUPP (was Re: xl save -c issues with Windows 7 Ultimate) Date: Wed, 11 May 2011 14:50:46 -0500 Message-ID: References: <1305016915.26692.261.camel@zakaz.uk.xensource.com> <4DC96FA50200007800040C69@vpn.id2.novell.com> <4DC97E000200007800040CFF@vpn.id2.novell.com> <4DCA5B3A0200007800040EC4@vpn.id2.novell.com> Reply-To: rshriram@cs.ubc.ca Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0548586238==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jan Beulich Cc: "xen-devel@lists.xensource.com" , Keir Fraser , Ian Campbell List-Id: xen-devel@lists.xenproject.org --===============0548586238== Content-Type: multipart/alternative; boundary=000325556532e00f4504a30565d3 --000325556532e00f4504a30565d3 Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 11, 2011 at 1:37 PM, Shriram Rajagopalan wrote: > On Wed, May 11, 2011 at 2:47 AM, Jan Beulich wrote: > >> >>> On 11.05.11 at 04:30, Shriram Rajagopalan wrote: >> >> I tried out a simple program that just gets and sets the VCPU 0's >> context >> > (no change >> > whatsoever to anything). There is no intermediate code involved (except >> for >> > the hypercall >> > bounce buffer stuff). If all is well, then this should work. But it >> doesnt!! >> > even for a PV guest. >> > I get the same Operation Not supported error when I try to "set" the >> vcpu >> > context with the >> > same struct obtained via the get_vcpucontext hypercall! >> >... >> > and I get - setcontext: operation not supported! >> >> Again, you'll want to add debugging code to the hypervisor to check >> what really is inconsistent. >> >> > now for the weirdness: >> > Since the the setcontext failed I thought I should be able >> > to run the above sample code again and again with no side effect >> > (please correct my assumption if I am wrong). >> > >> > But when I run the above code for the second time, I get a XEN panic! >> > >> > (XEN) Xen BUG at domctl.c:1724 >> > (XEN) ----[ Xen-4.2-unstable x86_64 debug=y Not tainted ]---- >> > (XEN) CPU: 2 >> > (XEN) RIP: e008:[] arch_get_info_guest+0x5f7/0x7b0 >> > (XEN) RFLAGS: 0000000000010202 CONTEXT: hypervisor >> > (XEN) rax: 0000000000000001 rbx: ffff8300228c4000 rcx: >> ffff8300228c4040 >> > (XEN) rdx: 0000000000000000 rsi: 0000000000000000 rdi: >> ffff830450652210 >> > (XEN) rbp: ffff83082a357da8 rsp: ffff83082a357d68 r8: >> 0000000000000002 >> > (XEN) r9: 0000000000000002 r10: 0000000000000040 r11: >> 0000000000000000 >> > (XEN) r12: ffff830450652010 r13: 0000000000000001 r14: >> ffff830829db9000 >> > (XEN) r15: ffff830450652010 cr0: 0000000080050033 cr4: >> 00000000000026f0 >> > (XEN) cr3: 000000047beef000 cr2: 0000000000d44048 >> > (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e010 cs: e008 >> > (XEN) Xen stack trace from rsp=ffff83082a357d68: >> > (XEN) ffff830829db9000 ffff8300228c4000 ffff83082a357d98 >> fffffffffffffff4 >> > (XEN) 0000000000d40004 ffff8300228c4000 ffff830829db9000 >> ffff830450652010 >> > (XEN) ffff83082a357ef8 ffff82c48010351f ffff83082a357e48 >> ffff82c48016af84 >> > (XEN) 0000000000000000 0000000000000070 ffff83082a357e28 >> 000000000047beea >> > (XEN) 0000000000000000 ffff83082a30b000 ffff830450652010 >> ffff830450652010 >> > (XEN) ffff83082a357e48 0000000080164c7d aaaaaaaaaaaaaaaa >> ffff83082a30b000 >> > (XEN) ffff83082a357ef8 ffff82c480113d73 000000070000000d >> 0000000000000001 >> > (XEN) 0000000000000000 0000000000d42004 0000000000000000 >> 00007fef43c4a791 >> > (XEN) 0000000000000001 0000000000000000 00007fff27dc7db0 >> 00007fef43a1bd58 >> > (XEN) 0000000000000024 0000000000000001 00007fff27dc9710 >> 0000000000000001 >> > (XEN) 0000000000d3f050 00007fef43c51325 0000000000000011 >> 00007fff27dc7dd0 >> > (XEN) ffff83082a357ed8 ffff8300bf656000 0000000000000003 >> 00007fff27dc7c60 >> > (XEN) 00007fff27dc7c60 0000000000000000 00007cf7d5ca80c7 >> ffff82c48020e1e8 >> > (XEN) ffffffff8100948a 0000000000000024 0000000000000000 >> 00007fff27dc7c60 >> > (XEN) 00007fff27dc7c60 0000000000000003 ffff8807a0f2fe68 >> ffffffff8148d700 >> > (XEN) 0000000000000282 0000000000000024 0000000000d3f050 >> 0000000000d40004 >> > (XEN) 0000000000000024 ffffffff8100948a 0000000100000000 >> 00007fff27dc7ce0 >> > (XEN) 0000000000d40004 0000010000000000 ffffffff8100948a >> 000000000000e033 >> > (XEN) 0000000000000282 ffff8807a0f2fe20 000000000000e02b >> 0000000000000000 >> > (XEN) 0000000000000000 0000000000000000 0000000000000000 >> 0000000000000002 >> > (XEN) Xen call trace: >> > (XEN) [] arch_get_info_guest+0x5f7/0x7b0 >> > (XEN) [] do_domctl+0x10ad/0x195e >> > (XEN) [] syscall_enter+0xc8/0x122 >> > >> > I would appreciate any pointers on how to go about this. >> >> This now indeed looks like an inconsistency between >> arch_get_info_guest() and the newly introduced error path in >> arch_set_info_guest() - the code to put v->arch.user_eflags into >> the necessary state now simply doesn't run anymore. It simply >> needs to be pulled up in that function (and a few other adjustments >> seem also necessary): >> >> --- a/xen/arch/x86/domain.c >> +++ b/xen/arch/x86/domain.c >> @@ -856,6 +856,15 @@ int arch_set_info_guest( >> goto out; >> } >> >> + init_int80_direct_trap(v); >> + >> + /* IOPL privileges are virtualised. */ >> + v->arch.pv_vcpu.iopl = (v->arch.user_regs.eflags >> 12) & 3; >> + v->arch.user_regs.eflags &= ~X86_EFLAGS_IOPL; >> + >> + /* Ensure real hardware interrupts are enabled. */ >> + v->arch.user_regs.eflags |= X86_EFLAGS_IF; >> + >> if ( !v->is_initialised ) >> { >> v->arch.pv_vcpu.ldt_base = c(ldt_base); >> @@ -866,7 +875,11 @@ int arch_set_info_guest( >> bool_t fail = v->arch.pv_vcpu.ctrlreg[3] != c(ctrlreg[3]); >> >> #ifdef CONFIG_X86_64 >> - fail |= v->arch.pv_vcpu.ctrlreg[1] != c(ctrlreg[1]); >> + if ( !compat ) >> + { >> + fail |= v->arch.pv_vcpu.ctrlreg[1] != c(ctrlreg[1]); >> + fail |= !v->arch.pv_vcpu.ctrlreg[1] && !(flags & >> VGCF_in_kernel); >> + } >> #endif >> >> for ( i = 0; i < ARRAY_SIZE(v->arch.pv_vcpu.gdt_frames); ++i ) >> @@ -907,15 +920,6 @@ int arch_set_info_guest( >> v->arch.pv_vcpu.ctrlreg[0] &= X86_CR0_TS; >> v->arch.pv_vcpu.ctrlreg[0] |= read_cr0() & ~X86_CR0_TS; >> >> - init_int80_direct_trap(v); >> - >> - /* IOPL privileges are virtualised. */ >> - v->arch.pv_vcpu.iopl = (v->arch.user_regs.eflags >> 12) & 3; >> - v->arch.user_regs.eflags &= ~X86_EFLAGS_IOPL; >> - >> - /* Ensure real hardware interrupts are enabled. */ >> - v->arch.user_regs.eflags |= X86_EFLAGS_IF; >> - >> cr4 = v->arch.pv_vcpu.ctrlreg[4]; >> v->arch.pv_vcpu.ctrlreg[4] = cr4 ? pv_guest_cr4_fixup(v, cr4) : >> real_cr4_to_pv_guest_cr4(mmu_cr4_features); >> >> Can you give this a try? > > Ok. This patch solves the Xen panic issue but not the EOPNOTSUPP > error. That is, I can use my sample program to "try" to get/set the same > vcpu > context. As usual, only get context succeeded and set context failed with > same EOPNOTSUPP error, for 2.6.18 32-bit domU and 2.6.39 64 bit dom0 > > And as you said, I added more debugging. > > (XEN) domain.c:893:d0 incoming cr3 42b33e000, cur cr3 827ba5000, fail = 1 > (XEN) domain.c:901:d0 incoming cr1 42ba6c000, cur cr1 00000000, !(flags & > VGCF_in_kernel)=0,fail=1 > > Looking at arch_get_info_guest in domctl.c , I see that cr3 is first copied verbatim from the vcpu and then modified in the if-else block if ( !is_pv_32on64_domain(v->domain) ) { c.nat->ctrlreg[3] = xen_pfn_to_cr3( pagetable_get_pfn(v->arch.guest_table)); #ifdef __x86_64__ c.nat->ctrlreg[1] = pagetable_is_null(v->arch.guest_table_user) ? 0 : xen_pfn_to_cr3(pagetable_get_pfn(v->arch.guest_table_user)); #endif .... } else { l4_pgentry_t *l4e = __va(pagetable_get_paddr(v->arch.guest_table)); c.cmp->ctrlreg[3] = compat_pfn_to_cr3(l4e_get_pfn(*l4e)); } This seems to account for the difference in the values that libxc supplies (obtained from get context) and the one validated against by arch_set_info_guest arch_set_context validates cr3 and cr1 against the wrong values (the vcpu.cr[1/3]) while it should be validated against the value that results from the operation done in the if-else loop in arch_get_info_guest I have verified this too, with both a 32bit domU and 64bit domU. 64-bit PV domU (2.6.39..) -------------------------------------- get_vcpu_context(): (debug output from arch_get_info_guest) (XEN) domctl.c:1707:d0 copying cr1 00000000 (XEN) domctl.c:1707:d0 copying cr3 827bd5000 (XEN) domctl.c:1743:d0 not pv_32on64, outgoing cr3 42b85b000, cur cr3 827bd5000 (XEN) domctl.c:1746:d0 not pv_32on64, outgoing cr1 42b85c000, cur cr1 00000000 set_vcpu_context(): (debug output from arch_set_info_guest) (XEN) domain.c:893:d0 incoming cr3 42b85b000, cur cr3 827bd5000, fail = 1 (XEN) domain.c:901:d0 incoming cr1 42b85c000, cur cr1 00000000, !(flags & VGCF_in_kernel)=0,fail=1 32-bit PV domU (2.6.18) ---------------------------------- get_vcpu_context() (XEN) domctl.c:1707:d0 copying cr1 00000000 (XEN) domctl.c:1707:d0 copying cr3 2960e008 (XEN) domctl.c:1758:d0 is pv_32on64, outgoing cr3 4f0ac004, cur cr3 2960e008 set_vcpu_context() (XEN) domain.c:893:d0 incoming cr3 4f0ac004, cur cr3 2960e008, fail = 1 shriram > corresponding code: > > bool_t fail = v->arch.pv_vcpu.ctrlreg[3] != c(ctrlreg[3]); > gdprintk(XENLOG_WARNING, > "incoming cr3 %08lx, cur cr3 %08lx, fail = %d\n", > c(ctrlreg[3]), v->arch.pv_vcpu.ctrlreg[3], fail); > > #ifdef CONFIG_X86_64 > > if ( !compat ) > { > fail |= v->arch.pv_vcpu.ctrlreg[1] != c(ctrlreg[1]); > gdprintk(XENLOG_WARNING, > "incoming cr1 %08lx, cur cr1 %08lx, !(flags & > VGCF_in_kernel)=%d,fail=%d\n", > c(ctrlreg[1]), v->arch.pv_vcpu.ctrlreg[1], !(flags & > VGCF_in_kernel),fail); > > fail |= !v->arch.pv_vcpu.ctrlreg[1] && !(flags & VGCF_in_kernel); > ... > > shriram > > The question is whether there are other inconsistencies lurking, and >> hence whether it wouldn't be better to mark a vCPU on which setting >> the context failed, not allowing it to resume or have its context >> obtained anymore. That appears quite drastic though - Keir, what's >> your opinion here? >> >> Jan >> >> > --000325556532e00f4504a30565d3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, May 11, 2011 at 1:37 PM, Shriram Rajagop= alan <rshriram@c= s.ubc.ca> wrote:
On Wed, May 11= , 2011 at 2:47 AM, Jan Beulich <JBeulich@novell.com> wrote= :
>>> On 11.05.11 at 04:30, Shriram Rajagopalan <rshriram@cs.ubc.ca> wro= te:
>> I tried out a simple program that just gets and sets the VCPU 0= 9;s context
> (no change
> whatsoever to anything). There is no intermediate code involved (excep= t for
> the hypercall
> bounce buffer stuff). If all is well, then this should work. But it do= esnt!!
> even for a PV guest.
> =A0I get the same Operation Not supported error when I try to "se= t" the vcpu
> context with the
> same struct obtained via the get_vcpucontext hypercall!
>...
> and I get - setcontext: operation not supported!

Again, you'll want to add debugging code to the hypervisor to che= ck
what really is inconsistent.

> now for the weirdness:
> =A0Since the the setcontext failed I thought I should be able
> to run the above sample code again and again with no side effect
> (please correct my assumption if I am wrong).
>
> But when I run the above code for the second time, I get a XEN panic!<= br> >
> (XEN) Xen BUG at domctl.c:1724
> (XEN) ----[ Xen-4.2-unstable =A0x86_64 =A0debug=3Dy =A0Not tainted ]--= --
> (XEN) CPU: =A0 =A02
> (XEN) RIP: =A0 =A0e008:[<ffff82c48014dd57>] arch_get_info_guest+= 0x5f7/0x7b0
> (XEN) RFLAGS: 0000000000010202 =A0 CONTEXT: hypervisor
> (XEN) rax: 0000000000000001 =A0 rbx: ffff8300228c4000 =A0 rcx: ffff830= 0228c4040
> (XEN) rdx: 0000000000000000 =A0 rsi: 0000000000000000 =A0 rdi: ffff830= 450652210
> (XEN) rbp: ffff83082a357da8 =A0 rsp: ffff83082a357d68 =A0 r8: =A000000= 00000000002
> (XEN) r9: =A00000000000000002 =A0 r10: 0000000000000040 =A0 r11: 00000= 00000000000
> (XEN) r12: ffff830450652010 =A0 r13: 0000000000000001 =A0 r14: ffff830= 829db9000
> (XEN) r15: ffff830450652010 =A0 cr0: 0000000080050033 =A0 cr4: 0000000= 0000026f0
> (XEN) cr3: 000000047beef000 =A0 cr2: 0000000000d44048
> (XEN) ds: 0000 =A0 es: 0000 =A0 fs: 0000 =A0 gs: 0000 =A0 ss: e010 =A0= cs: e008
> (XEN) Xen stack trace from rsp=3Dffff83082a357d68:
> (XEN) =A0 =A0ffff830829db9000 ffff8300228c4000 ffff83082a357d98 ffffff= fffffffff4
> (XEN) =A0 =A00000000000d40004 ffff8300228c4000 ffff830829db9000 ffff83= 0450652010
> (XEN) =A0 =A0ffff83082a357ef8 ffff82c48010351f ffff83082a357e48 ffff82= c48016af84
> (XEN) =A0 =A00000000000000000 0000000000000070 ffff83082a357e28 000000= 000047beea
> (XEN) =A0 =A00000000000000000 ffff83082a30b000 ffff830450652010 ffff83= 0450652010
> (XEN) =A0 =A0ffff83082a357e48 0000000080164c7d aaaaaaaaaaaaaaaa ffff83= 082a30b000
> (XEN) =A0 =A0ffff83082a357ef8 ffff82c480113d73 000000070000000d 000000= 0000000001
> (XEN) =A0 =A00000000000000000 0000000000d42004 0000000000000000 00007f= ef43c4a791
> (XEN) =A0 =A00000000000000001 0000000000000000 00007fff27dc7db0 00007f= ef43a1bd58
> (XEN) =A0 =A00000000000000024 0000000000000001 00007fff27dc9710 000000= 0000000001
> (XEN) =A0 =A00000000000d3f050 00007fef43c51325 0000000000000011 00007f= ff27dc7dd0
> (XEN) =A0 =A0ffff83082a357ed8 ffff8300bf656000 0000000000000003 00007f= ff27dc7c60
> (XEN) =A0 =A000007fff27dc7c60 0000000000000000 00007cf7d5ca80c7 ffff82= c48020e1e8
> (XEN) =A0 =A0ffffffff8100948a 0000000000000024 0000000000000000 00007f= ff27dc7c60
> (XEN) =A0 =A000007fff27dc7c60 0000000000000003 ffff8807a0f2fe68 ffffff= ff8148d700
> (XEN) =A0 =A00000000000000282 0000000000000024 0000000000d3f050 000000= 0000d40004
> (XEN) =A0 =A00000000000000024 ffffffff8100948a 0000000100000000 00007f= ff27dc7ce0
> (XEN) =A0 =A00000000000d40004 0000010000000000 ffffffff8100948a 000000= 000000e033
> (XEN) =A0 =A00000000000000282 ffff8807a0f2fe20 000000000000e02b 000000= 0000000000
> (XEN) =A0 =A00000000000000000 0000000000000000 0000000000000000 000000= 0000000002
> (XEN) Xen call trace:
> (XEN) =A0 =A0[<ffff82c48014dd57>] arch_get_info_guest+0x5f7/0x7b= 0
> (XEN) =A0 =A0[<ffff82c48010351f>] do_domctl+0x10ad/0x195e
> (XEN) =A0 =A0[<ffff82c48020e1e8>] syscall_enter+0xc8/0x122
>
> I would appreciate any pointers on how to go about this.

This now indeed looks like an inconsistency between
arch_get_info_guest() and the newly introduced error path in
arch_set_info_guest() - the code to put v->arch.user_eflags into
the necessary state now simply doesn't run anymore. It simply
needs to be pulled up in that function (and a few other adjustments
seem also necessary):

--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -856,6 +856,15 @@ int arch_set_info_guest(
=A0 =A0 =A0 =A0 goto out;
=A0 =A0 }

+ =A0 =A0init_int80_direct_trap(v);
+
+ =A0 =A0/* IOPL privileges are virtualised. */
+ =A0 =A0v->arch.pv_vcpu.iopl =3D (v->arch.user_regs.eflags >> = 12) & 3;
+ =A0 =A0v->arch.user_regs.eflags &=3D ~X86_EFLAGS_IOPL;
+
+ =A0 =A0/* Ensure real hardware interrupts are enabled. */
+ =A0 =A0v->arch.user_regs.eflags |=3D X86_EFLAGS_IF;
+
=A0 =A0 if ( !v->is_initialised )
=A0 =A0 {
=A0 =A0 =A0 =A0 v->arch.pv_vcpu.ldt_base =3D c(ldt_base);
@@ -866,7 +875,11 @@ int arch_set_info_guest(
=A0 =A0 =A0 =A0 bool_t fail =3D v->arch.pv_vcpu.ctrlreg[3] !=3D c(= ctrlreg[3]);

=A0#ifdef CONFIG_X86_64
- =A0 =A0 =A0 =A0fail |=3D v->arch.pv_vcpu.ctrlreg[1] !=3D c(ctrlreg[1])= ;
+ =A0 =A0 =A0 =A0if ( !compat )
+ =A0 =A0 =A0 =A0{
+ =A0 =A0 =A0 =A0 =A0 =A0fail |=3D v->arch.pv_vcpu.ctrlreg[1] !=3D c(ctr= lreg[1]);
+ =A0 =A0 =A0 =A0 =A0 =A0fail |=3D !v->arch.pv_vcpu.ctrlreg[1] &&= ; !(flags & VGCF_in_kernel);
+ =A0 =A0 =A0 =A0}
=A0#endif

=A0 =A0 =A0 =A0 for ( i =3D 0; i < ARRAY_SIZE(v->arch.pv_vcpu.gdt_fr= ames); ++i )
@@ -907,15 +920,6 @@ int arch_set_info_guest(
=A0 =A0 v->arch.pv_vcpu.ctrlreg[0] &=3D X86_CR0_TS;
=A0 =A0 v->arch.pv_vcpu.ctrlreg[0] |=3D read_cr0() & ~X86_CR0_TS;
- =A0 =A0init_int80_direct_trap(v);
-
- =A0 =A0/* IOPL privileges are virtualised. */
- =A0 =A0v->arch.pv_vcpu.iopl =3D (v->arch.user_regs.eflags >> = 12) & 3;
- =A0 =A0v->arch.user_regs.eflags &=3D ~X86_EFLAGS_IOPL;
-
- =A0 =A0/* Ensure real hardware interrupts are enabled. */
- =A0 =A0v->arch.user_regs.eflags |=3D X86_EFLAGS_IF;
-
=A0 =A0 cr4 =3D v->arch.pv_vcpu.ctrlreg[4];
=A0 =A0 v->arch.pv_vcpu.ctrlreg[4] =3D cr4 ? pv_guest_cr4_fixup(v, cr4)= :
=A0 =A0 =A0 =A0 real_cr4_to_pv_guest_cr4(mmu_cr4_features);

Can you give this a try?
Ok. This patch solves= the Xen panic issue but not the EOPNOTSUPP
error. That is, I can use my= sample program to "try" to get/set the same vcpu
context. As = usual, only get context succeeded and set context failed with
same EOPNOTSUPP error, for 2.6.18 32-bit domU and 2.6.39 64 bit dom0
And as you said, I added more debugging.

(XEN) domain.c:893:d0 inco= ming cr3 42b33e000, cur cr3 827ba5000, fail =3D 1
(XEN) domain.c:901:d0 incoming cr1 42ba6c000, cur cr1 00000000, !(flags &am= p; VGCF_in_kernel)=3D0,fail=3D1

Lookin= g at arch_get_info_guest in domctl.c , I see that cr3 is first copied verba= tim from the vcpu and
then modified in the if-else block
if ( !is_pv_32on64_domain(v->domai= n) )
=A0=A0=A0=A0=A0=A0=A0 {
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 c.nat-= >ctrlreg[3] =3D xen_pfn_to_cr3(
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 pagetable_get_pfn(v->arch.guest_table));
#ifdef __x86_64__<= br> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 c.nat->ctrlreg[1] =3D
=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 pagetable_is_null(v->arch.guest_table_= user) ? 0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : xen_pfn_to_cr3= (pagetable_get_pfn(v->arch.guest_table_user));
#endif
....
=A0= =A0 } else {
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 l4_pgentry_t *l4e =3D __va(pagetable_get_= paddr(v->arch.guest_table));
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 c.cmp-= >ctrlreg[3] =3D compat_pfn_to_cr3(l4e_get_pfn(*l4e));
}

This = seems to account for the difference in the values that libxc supplies (obta= ined from get context)
and the one validated against by arch_set_info_guest
=A0arch_set_context= validates cr3 and cr1 against the wrong values (the vcpu.cr[1/3]) while it should
=A0be validated against the value= that results from the operation done in the if-else loop in arch_get_info_= guest

I have verified this too, with both a 32bit domU and 64bit domU.
64-bit PV domU (2.6.39..)
--------------------------------------
get= _vcpu_context(): (debug output from arch_get_info_guest)
(XEN) domctl.c:= 1707:d0=A0 copying cr1 00000000
(XEN) domctl.c:1707:d0=A0 copying cr3 827bd5000
(XEN) domctl.c:1743:d0 n= ot pv_32on64, outgoing cr3 42b85b000, cur cr3 827bd5000
(XEN) domctl.c:1= 746:d0 not pv_32on64, outgoing cr1 42b85c000, cur cr1 00000000

set_v= cpu_context(): (debug output from arch_set_info_guest)
(XEN) domain.c:893:d0 incoming cr3 42b85b000, cur cr3 827bd5000, fail =3D 1=
(XEN) domain.c:901:d0 incoming cr1 42b85c000, cur cr1 00000000, !(flags= & VGCF_in_kernel)=3D0,fail=3D1

32-bit PV domU (2.6.18)
-----= -----------------------------
get_vcpu_context()
(XEN) domctl.c:1707:d0 copying cr1 00000000
(XEN) = domctl.c:1707:d0 copying cr3 2960e008
(XEN) domctl.c:1758:d0 is pv_32on6= 4, outgoing cr3 4f0ac004, cur cr3 2960e008

set_vcpu_context()
(XEN) domain.c:893:d0 incoming cr3 4f0ac004, cur cr3 2960e008, fail =3D 1

shriram
corresponding code:

bo= ol_t fail =3D v->arch.pv_vcpu.ctrlreg[3] !=3D c(ctrlreg[3]);
gd= printk(XENLOG_WARNING,
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "incoming cr3 %08lx, cur cr3 %08lx, = fail =3D %d\n",
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 c(ctrlreg[3]),= v->arch.pv_vcpu.ctrlreg[3], fail);

#ifdef CONFIG_X86_64

if ( !compat )
{
=A0=A0=A0=A0=A0 fail |=3D v->arch.pv= _vcpu.ctrlreg[1] !=3D c(ctrlreg[1]);
=A0=A0=A0=A0=A0 gdprintk(XENLOG_WARNING,
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 "incoming cr1 %08lx, cur cr1 %08lx, !(flags & VGCF= _in_kernel)=3D%d,fail=3D%d\n",
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 c(ctrlreg[1]), v->arch.pv_vcpu.ctrlreg[1], !(flags & VG= CF_in_kernel),fail);

=A0=A0=A0=A0=A0 fail |=3D !v->arch.pv_vcpu.ctrlreg[1] && !(flags= & VGCF_in_kernel);
...

shriram=

The question is whether there are other inconsistencies lurking, and
hence whether it wouldn't be better to mark a vCPU on which setting
the context failed, not allowing it to resume or have its context
obtained anymore. That appears quite drastic though - Keir, what's
your opinion here?

Jan



--000325556532e00f4504a30565d3-- --===============0548586238== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0548586238==--