Shriram Rajagopalan
2011-May-09 23:06 UTC
xl/xm save -c fails - set_vcpucontext EOPNOTSUPP (was Re: [Xen-devel] xl save -c issues with Windows 7 Ultimate)
I was testing xl/xm checkpoint with the latest c/s in the repo, 23300. neither xl nor xm seem to work. The error code is 95 (EOPNOTSUPP). Migration works but not checkpointing. While doing a xc_domain_resume, the "modify_returncode" phase (for suspend_cancel) fails. Tracing through the control flow, I found that the hypercall for set_vcpucontext (in do_xen_hypercall() from xc_private.c) fails with this error code. I have tested this with a 64-bit 2.6.39 and 32-bit 2.6.18 pv domU. Any help would be great. shriram On Fri, May 6, 2011 at 5:01 PM, AP Xen <apxeng@gmail.com> wrote:> On Tue, May 3, 2011 at 4:07 AM, George Dunlap > <George.Dunlap@eu.citrix.com> wrote: > > Have you tried it with other operating systems and found it to work? > > I.e., is it something specific to Windows 7, or is it a general HVM / > > Windows problem? > > I tried this with CentOS 5.6 and saw the same behavior. > > root@ubuntu:~# xl -vvv save -c centos /etc/xen/centoschk > Saving to /etc/xen/centoschk new xl format (info 0x0/0x0/255) > libxl: debug: libxl_dom.c:384:libxl__domain_suspend_common_callback > issuing PVHVM suspend request via XenBus control node > libxl: debug: libxl_dom.c:389:libxl__domain_suspend_common_callback > wait for the guest to acknowledge suspend request > libxl: debug: libxl_dom.c:434:libxl__domain_suspend_common_callback > guest acknowledged suspend request > libxl: debug: libxl_dom.c:438:libxl__domain_suspend_common_callback > wait for the guest to suspend > libxl: debug: libxl_dom.c:450:libxl__domain_suspend_common_callback > guest has suspended > xc: debug: outbuf_write: 4194304 > 90092@16687124 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: debug: outbuf_write: 4194304 > 4169716@12607500 > xc: detail: type fail: page 0 mfn 000f2000 > xc: detail: type fail: page 1 mfn 000f2001 > xc: detail: type fail: page 2 mfn 000f2002 > xc: detail: delta 9371ms, dom0 25%, target 0%, sent 920Mb/s, dirtied > 0Mb/s 0 pages > xc: detail: Total pages sent= 263168 (0.25x) > xc: detail: (of which 0 were fixups) > xc: detail: All memory is saved > xc: detail: Save exit rc=0 > libxl: debug: libxl_dom.c:534:libxl__domain_save_device_model Saving > device model state to /var/lib/xen/qemu-save.7 > libxl: debug: libxl_dom.c:546:libxl__domain_save_device_model Qemu > state is 7204 bytes > > > root@ubuntu:~# xl list > Name ID Mem VCPUs State > Time(s) > Domain-0 0 2914 4 r----- > 6576.4 > centos 7 1019 2 ---ss- > 575.4 > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Campbell
2011-May-10 08:41 UTC
Re: xl/xm save -c fails - set_vcpucontext EOPNOTSUPP (was Re: [Xen-devel] xl save -c issues with Windows 7 Ultimate)
On Tue, 2011-05-10 at 00:06 +0100, Shriram Rajagopalan wrote:> I was testing xl/xm checkpoint with the latest c/s in the repo, 23300. > neither xl nor xm seem to work. The error code is 95 (EOPNOTSUPP). > > Migration works but not checkpointing. While doing a > xc_domain_resume, > the "modify_returncode" phase (for suspend_cancel) fails. Tracing > through > the control flow, I found that the hypercall for set_vcpucontext > (in do_xen_hypercall() from xc_private.c) fails with this error code. > > I have tested this with a 64-bit 2.6.39 and 32-bit 2.6.18 pv domU. > Any help would be great.Are we still talking about HVM guests? The most plausible looking EOPNOTSUPP from that code is in xen/arch/x86/domain.c:arch_set_info_guest() but that is on a PV only path. There are only a small number of uses of EOPNOTSUPP in the hypervisor and the rest are all in xen/arch/x86/hvm/hvm.c or xen/arch/x86/hvm/nestedhvm.c and all are in nestedhvm related functions. I guess you aren''t using nested HVM though?! Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Shriram Rajagopalan
2011-May-10 14:52 UTC
Re: xl/xm save -c fails - set_vcpucontext EOPNOTSUPP (was Re: [Xen-devel] xl save -c issues with Windows 7 Ultimate)
On Tue, May 10, 2011 at 3:41 AM, Ian Campbell <Ian.Campbell@citrix.com>wrote:> On Tue, 2011-05-10 at 00:06 +0100, Shriram Rajagopalan wrote: > > I was testing xl/xm checkpoint with the latest c/s in the repo, 23300. > > neither xl nor xm seem to work. The error code is 95 (EOPNOTSUPP). > > > > Migration works but not checkpointing. While doing a > > xc_domain_resume, > > the "modify_returncode" phase (for suspend_cancel) fails. Tracing > > through > > the control flow, I found that the hypercall for set_vcpucontext > > (in do_xen_hypercall() from xc_private.c) fails with this error code. > > > > I have tested this with a 64-bit 2.6.39 and 32-bit 2.6.18 pv domU. > > Any help would be great. > > Are we still talking about HVM guests? > > No! its all PV. There is a 2.6.39-rc1 debian guest and a 2.6.18 standardxenlinux kernel based debian guest.> The most plausible looking EOPNOTSUPP from that code is in > xen/arch/x86/domain.c:arch_set_info_guest() but that is on a PV only > path. > > And that rings with the pv guests I am using. It makes perfect sense,looking at that function and especially at the code that returns EOPNOTSUPP (the only place in the entire file). else { 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]); #endif for ( i = 0; i < ARRAY_SIZE(v->arch.pv_vcpu.gdt_frames); ++i ) fail |= v->arch.pv_vcpu.gdt_frames[i] != c(gdt_frames[i]); fail |= v->arch.pv_vcpu.gdt_ents != c(gdt_ents); fail |= v->arch.pv_vcpu.ldt_base != c(ldt_base); fail |= v->arch.pv_vcpu.ldt_ents != c(ldt_ents); if ( fail ) return -EOPNOTSUPP; } This change was introduced by c/s changeset: 23142:f5e8d152a565 user: Jan Beulich <jbeulich@novell.com> date: Tue Apr 05 13:01:25 2011 +0100 x86: split struct vcpu I think I am missing something really obvious in this piece of code. The xc_domain_resume code tries to modify the return value of shutdown hypercall (i.e eax register is set to 1) and this code doesnt seem to check those registers. There are only a small number of uses of EOPNOTSUPP in the hypervisor> and the rest are all in xen/arch/x86/hvm/hvm.c or > xen/arch/x86/hvm/nestedhvm.c and all are in nestedhvm related functions. > I guess you aren''t using nested HVM though?! > > Nope> Ian. > > > shriram_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jan Beulich
2011-May-10 15:02 UTC
Re: xl/xm save -c fails - set_vcpucontext EOPNOTSUPP (was Re: [Xen-devel] xl save -c issues with Windows 7 Ultimate)
>>> On 10.05.11 at 16:52, Shriram Rajagopalan <rshriram@cs.ubc.ca> wrote: > On Tue, May 10, 2011 at 3:41 AM, Ian Campbell <Ian.Campbell@citrix.com>wrote: >> The most plausible looking EOPNOTSUPP from that code is in >> xen/arch/x86/domain.c:arch_set_info_guest() but that is on a PV only >> path. >> >> And that rings with the pv guests I am using. It makes perfect sense, > looking > at that function and especially at the code that returns EOPNOTSUPP (the > only > place in the entire file). > else > { > 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]); > #endif > > for ( i = 0; i < ARRAY_SIZE(v->arch.pv_vcpu.gdt_frames); ++i ) > fail |= v->arch.pv_vcpu.gdt_frames[i] != c(gdt_frames[i]); > fail |= v->arch.pv_vcpu.gdt_ents != c(gdt_ents); > > fail |= v->arch.pv_vcpu.ldt_base != c(ldt_base); > fail |= v->arch.pv_vcpu.ldt_ents != c(ldt_ents); > > if ( fail ) > return -EOPNOTSUPP; > } > > This change was introduced by c/s > changeset: 23142:f5e8d152a565 > user: Jan Beulich <jbeulich@novell.com> > date: Tue Apr 05 13:01:25 2011 +0100 > x86: split struct vcpu > > I think I am missing something really obvious in this piece of code. The > xc_domain_resume code tries to modify the return value of shutdown hypercall > (i.e eax register is set to 1) and this code doesnt seem to check those > registers.Correct - the code here checks only for values where the logic needed to support changing the on an already initialized vCPU isn''t implemented. Previously, actual vCPU state and what was tracked in struct vcpu could get out of sync in this case, potentially confusing things further down (including possible security issues). You''ll want to figure out which part(s) actually differ, and why. Only then we''ll be able to tell whether mentioned c/s introduced false positives. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Shriram Rajagopalan
2011-May-10 15:50 UTC
Re: xl/xm save -c fails - set_vcpucontext EOPNOTSUPP (was Re: [Xen-devel] xl save -c issues with Windows 7 Ultimate)
On Tue, May 10, 2011 at 10:02 AM, Jan Beulich <JBeulich@novell.com> wrote:> >>> On 10.05.11 at 16:52, Shriram Rajagopalan <rshriram@cs.ubc.ca> wrote: > > On Tue, May 10, 2011 at 3:41 AM, Ian Campbell <Ian.Campbell@citrix.com > >wrote: > >> The most plausible looking EOPNOTSUPP from that code is in > >> xen/arch/x86/domain.c:arch_set_info_guest() but that is on a PV only > >> path. > >> > >> And that rings with the pv guests I am using. It makes perfect sense, > > looking > > at that function and especially at the code that returns EOPNOTSUPP (the > > only > > place in the entire file). > > else > > { > > 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]); > > #endif > > > > for ( i = 0; i < ARRAY_SIZE(v->arch.pv_vcpu.gdt_frames); ++i ) > > fail |= v->arch.pv_vcpu.gdt_frames[i] != c(gdt_frames[i]); > > fail |= v->arch.pv_vcpu.gdt_ents != c(gdt_ents); > > > > fail |= v->arch.pv_vcpu.ldt_base != c(ldt_base); > > fail |= v->arch.pv_vcpu.ldt_ents != c(ldt_ents); > > > > if ( fail ) > > return -EOPNOTSUPP; > > } > > > > This change was introduced by c/s > > changeset: 23142:f5e8d152a565 > > user: Jan Beulich <jbeulich@novell.com> > > date: Tue Apr 05 13:01:25 2011 +0100 > > x86: split struct vcpu > > > > I think I am missing something really obvious in this piece of code. The > > xc_domain_resume code tries to modify the return value of shutdown > hypercall > > (i.e eax register is set to 1) and this code doesnt seem to check those > > registers. > > Correct - the code here checks only for values where the logic > needed to support changing the on an already initialized vCPU isn''t > implemented. Previously, actual vCPU state and what was tracked > in struct vcpu could get out of sync in this case, potentially > confusing things further down (including possible security issues). > > You''ll want to figure out which part(s) actually differ, and why. > Only then we''ll be able to tell whether mentioned c/s introduced > false positives. > > Bit confused. If I understand correctly, this piece of code checks newvalues of certain registers against old ones, for an already initialized VCPU. And AFAIT, it is checking the gdts, ldts & control registers. The xc_domain_resume code just changes one general purpose register eax. basically, get_vcpucontext() set_field(eax, 1) //to indicate SUSPEND_CANCEL set_vcpucontext() I dont understand what you mean by "which parts actually differ & why". And just a trivial question: is the hypervisor binary always compiled to a 32-bit elf? somehow, the symbols file xen-syms-* is getting compiled to 64 bit ELF binary while the xen binary is getting compiled to 32-bit binary. shriram> Jan > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Campbell
2011-May-10 15:55 UTC
Re: xl/xm save -c fails - set_vcpucontext EOPNOTSUPP (was Re: [Xen-devel] xl save -c issues with Windows 7 Ultimate)
On Tue, 2011-05-10 at 16:50 +0100, Shriram Rajagopalan wrote:> On Tue, May 10, 2011 at 10:02 AM, Jan Beulich <JBeulich@novell.com> > wrote: > >>> On 10.05.11 at 16:52, Shriram Rajagopalan > <rshriram@cs.ubc.ca> wrote: > > On Tue, May 10, 2011 at 3:41 AM, Ian Campbell > <Ian.Campbell@citrix.com>wrote: > > > >> The most plausible looking EOPNOTSUPP from that code is in > >> xen/arch/x86/domain.c:arch_set_info_guest() but that is on > a PV only > >> path. > >> > >> And that rings with the pv guests I am using. It makes > perfect sense, > > looking > > at that function and especially at the code that returns > EOPNOTSUPP (the > > only > > place in the entire file). > > else > > { > > 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]); > > #endif > > > > for ( i = 0; i < > ARRAY_SIZE(v->arch.pv_vcpu.gdt_frames); ++i ) > > fail |= v->arch.pv_vcpu.gdt_frames[i] !> c(gdt_frames[i]); > > fail |= v->arch.pv_vcpu.gdt_ents != c(gdt_ents); > > > > fail |= v->arch.pv_vcpu.ldt_base != c(ldt_base); > > fail |= v->arch.pv_vcpu.ldt_ents != c(ldt_ents); > > > > if ( fail ) > > return -EOPNOTSUPP; > > } > > > > This change was introduced by c/s > > changeset: 23142:f5e8d152a565 > > user: Jan Beulich <jbeulich@novell.com> > > date: Tue Apr 05 13:01:25 2011 +0100 > > x86: split struct vcpu > > > > I think I am missing something really obvious in this piece > of code. The > > xc_domain_resume code tries to modify the return value of > shutdown hypercall > > (i.e eax register is set to 1) and this code doesnt seem to > check those > > registers. > > > Correct - the code here checks only for values where the logic > needed to support changing the on an already initialized vCPU > isn''t > implemented. Previously, actual vCPU state and what was > tracked > in struct vcpu could get out of sync in this case, potentially > confusing things further down (including possible security > issues). > > You''ll want to figure out which part(s) actually differ, and > why. > Only then we''ll be able to tell whether mentioned c/s > introduced > false positives. > > Bit confused. If I understand correctly, this piece of code checks new > values > of certain registers against old ones, for an already initialized > VCPU. And AFAIT, > it is checking the gdts, ldts & control registers. The > xc_domain_resume code just > changes one general purpose register eax. basically, > > get_vcpucontext() > set_field(eax, 1) //to indicate SUSPEND_CANCEL > set_vcpucontext() > > I dont understand what you mean by "which parts actually differ & > why".Either get_vcpucontext is returning something "odd" or set_vcpucontext is being overzealous in what it checks (the "false positives" Jan refers too)> And just a trivial question: > is the hypervisor binary always compiled to a 32-bit elf? somehow, the > symbols file xen-syms-* is getting compiled to 64 bit ELF binary while > the xen binary is getting compiled to 32-bit binary.The hypervisor binary (32 or 64 bit) is always wrapped up as a 32 bit ELF, see the use of xen/arch/x86/boot/mkelf32.c. Something to do with keeping a bootloader happy, I think... Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jan Beulich
2011-May-10 16:03 UTC
Re: xl/xm save -c fails - set_vcpucontext EOPNOTSUPP (was Re: [Xen-devel] xl save -c issues with Windows 7 Ultimate)
>>> On 10.05.11 at 17:50, Shriram Rajagopalan <rshriram@cs.ubc.ca> wrote: > On Tue, May 10, 2011 at 10:02 AM, Jan Beulich <JBeulich@novell.com> wrote: > >> >>> On 10.05.11 at 16:52, Shriram Rajagopalan <rshriram@cs.ubc.ca> wrote: >> > On Tue, May 10, 2011 at 3:41 AM, Ian Campbell <Ian.Campbell@citrix.com >> >wrote: >> >> The most plausible looking EOPNOTSUPP from that code is in >> >> xen/arch/x86/domain.c:arch_set_info_guest() but that is on a PV only >> >> path. >> >> >> >> And that rings with the pv guests I am using. It makes perfect sense, >> > looking >> > at that function and especially at the code that returns EOPNOTSUPP (the >> > only >> > place in the entire file). >> > else >> > { >> > 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]); >> > #endif >> > >> > for ( i = 0; i < ARRAY_SIZE(v->arch.pv_vcpu.gdt_frames); ++i ) >> > fail |= v->arch.pv_vcpu.gdt_frames[i] != c(gdt_frames[i]); >> > fail |= v->arch.pv_vcpu.gdt_ents != c(gdt_ents); >> > >> > fail |= v->arch.pv_vcpu.ldt_base != c(ldt_base); >> > fail |= v->arch.pv_vcpu.ldt_ents != c(ldt_ents); >> > >> > if ( fail ) >> > return -EOPNOTSUPP; >> > } >> > >> > This change was introduced by c/s >> > changeset: 23142:f5e8d152a565 >> > user: Jan Beulich <jbeulich@novell.com> >> > date: Tue Apr 05 13:01:25 2011 +0100 >> > x86: split struct vcpu >> > >> > I think I am missing something really obvious in this piece of code. The >> > xc_domain_resume code tries to modify the return value of shutdown >> hypercall >> > (i.e eax register is set to 1) and this code doesnt seem to check those >> > registers. >> >> Correct - the code here checks only for values where the logic >> needed to support changing the on an already initialized vCPU isn''t >> implemented. Previously, actual vCPU state and what was tracked >> in struct vcpu could get out of sync in this case, potentially >> confusing things further down (including possible security issues). >> >> You''ll want to figure out which part(s) actually differ, and why. >> Only then we''ll be able to tell whether mentioned c/s introduced >> false positives. >> >> Bit confused. If I understand correctly, this piece of code checks new > values > of certain registers against old ones, for an already initialized VCPU. And > AFAIT, > it is checking the gdts, ldts & control registers. The xc_domain_resume code > just > changes one general purpose register eax. basically, > > get_vcpucontext() > set_field(eax, 1) //to indicate SUSPEND_CANCEL > set_vcpucontext() > > I dont understand what you mean by "which parts actually differ & why".Quite obviously there are differences in one or more of the now checked fields, and we need to find out where they are (and why). This is regardless of the tools apparently only modifying eax.> And just a trivial question: > is the hypervisor binary always compiled to a 32-bit elf? somehow, the > symbols file xen-syms-* is getting compiled to 64 bit ELF binary while > the xen binary is getting compiled to 32-bit binary.Yes, that''s because it wants to boot from 32-bit GrUB (and the multiboot protocol also is 32-bit only afaik). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Shriram Rajagopalan
2011-May-11 02:30 UTC
Re: xl/xm save -c fails - set_vcpucontext EOPNOTSUPP (was Re: [Xen-devel] xl save -c issues with Windows 7 Ultimate)
On Tue, May 10, 2011 at 11:03 AM, Jan Beulich <JBeulich@novell.com> wrote:> >>> On 10.05.11 at 17:50, Shriram Rajagopalan <rshriram@cs.ubc.ca> wrote: > > On Tue, May 10, 2011 at 10:02 AM, Jan Beulich <JBeulich@novell.com> > wrote: > > > >> >>> On 10.05.11 at 16:52, Shriram Rajagopalan <rshriram@cs.ubc.ca> > wrote: > >> > On Tue, May 10, 2011 at 3:41 AM, Ian Campbell < > Ian.Campbell@citrix.com > >> >wrote: > >> >> The most plausible looking EOPNOTSUPP from that code is in > >> >> xen/arch/x86/domain.c:arch_set_info_guest() but that is on a PV only > >> >> path. > >> >> > >> >> And that rings with the pv guests I am using. It makes perfect sense, > >> > looking > >> > at that function and especially at the code that returns EOPNOTSUPP > (the > >> > only > >> > place in the entire file). > >> > else > >> > { > >> > 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]); > >> > #endif > >> > > >> > for ( i = 0; i < ARRAY_SIZE(v->arch.pv_vcpu.gdt_frames); ++i ) > >> > fail |= v->arch.pv_vcpu.gdt_frames[i] != c(gdt_frames[i]); > >> > fail |= v->arch.pv_vcpu.gdt_ents != c(gdt_ents); > >> > > >> > fail |= v->arch.pv_vcpu.ldt_base != c(ldt_base); > >> > fail |= v->arch.pv_vcpu.ldt_ents != c(ldt_ents); > >> > > >> > if ( fail ) > >> > return -EOPNOTSUPP; > >> > } > >> > > >> > This change was introduced by c/s > >> > changeset: 23142:f5e8d152a565 > >> > user: Jan Beulich <jbeulich@novell.com> > >> > date: Tue Apr 05 13:01:25 2011 +0100 > >> > x86: split struct vcpu > >> > > >> > I think I am missing something really obvious in this piece of code. > The > >> > xc_domain_resume code tries to modify the return value of shutdown > >> hypercall > >> > (i.e eax register is set to 1) and this code doesnt seem to check > those > >> > registers. > >> > >> Correct - the code here checks only for values where the logic > >> needed to support changing the on an already initialized vCPU isn''t > >> implemented. Previously, actual vCPU state and what was tracked > >> in struct vcpu could get out of sync in this case, potentially > >> confusing things further down (including possible security issues). > >> > >> You''ll want to figure out which part(s) actually differ, and why. > >> Only then we''ll be able to tell whether mentioned c/s introduced > >> false positives. > >> > >> Bit confused. If I understand correctly, this piece of code checks new > > values > > of certain registers against old ones, for an already initialized VCPU. > And > > AFAIT, > > it is checking the gdts, ldts & control registers. The xc_domain_resume > code > > just > > changes one general purpose register eax. basically, > > > > get_vcpucontext() > > set_field(eax, 1) //to indicate SUSPEND_CANCEL > > set_vcpucontext() > > > > I dont understand what you mean by "which parts actually differ & why". > > Quite obviously there are differences in one or more of the now > checked fields, and we need to find out where they are (and > why). This is regardless of the tools apparently only modifying > eax. > > > And just a trivial question: > > is the hypervisor binary always compiled to a 32-bit elf? somehow, the > > symbols file xen-syms-* is getting compiled to 64 bit ELF binary while > > the xen binary is getting compiled to 32-bit binary. > > Yes, that''s because it wants to boot from 32-bit GrUB (and the > multiboot protocol also is 32-bit only afaik). > > Jan > > 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! Setup: 32bit 2.6.18 32-bit domU, 2.6.32.39 64-bit dom0, 64-bit xen-unstable c/s 23300, I suspend the domain via usual xenstore suspend. The code for get/set vcpu context was taken verbatim from tools/libxc/xc_resume.c:modify_returncode (just commented out the SET_FIELD line, that changes eax) static int pv_guest_width(xc_interface *xch, uint32_t domid) { DECLARE_DOMCTL; domctl.domain = domid; domctl.cmd = XEN_DOMCTL_get_address_size; if ( xc_domctl(xch, &domctl) != 0 ) { perror("Could not get guest address size"); return -1; } return domctl.u.address_size.size / 8; } static int get_set_vcpu_ctx(xc_interface *xch, unsigned int domid) { vcpu_guest_context_any_t ctxt; xc_dominfo_t info; xen_capabilities_info_t caps; struct domain_info_context _dinfo = {}; struct domain_info_context *dinfo = &_dinfo; int rc; if ( xc_domain_getinfo(xch, domid, 1, &info) != 1 ) { perror("Could not get domain info"); return -1; } /* Probe PV guest address width. */ dinfo->guest_width = pv_guest_width(xch, domid); if ( dinfo->guest_width < 0 ) return -1; if ( (rc = xc_vcpu_getcontext(xch, domid, 0, &ctxt)) != 0 ) { perror("getcontext failed"); return rc; } // SET_FIELD(&ctxt, user_regs.eax, 1); if ( (rc = xc_vcpu_setcontext(xch, domid, 0, &ctxt)) != 0 ) { perror("setcontext failed"); return rc; } fprintf(stderr, "get/set vcpu context succeeded\n"); return 0; } and I get - setcontext: operation not supported! 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:[<ffff82c48014dd57>] 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) [<ffff82c48014dd57>] arch_get_info_guest+0x5f7/0x7b0 (XEN) [<ffff82c48010351f>] do_domctl+0x10ad/0x195e (XEN) [<ffff82c48020e1e8>] syscall_enter+0xc8/0x122 I would appreciate any pointers on how to go about this. shriram _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jan Beulich
2011-May-11 07:47 UTC
Re: xl/xm save -c fails - set_vcpucontext EOPNOTSUPP (was Re: [Xen-devel] xl save -c issues with Windows 7 Ultimate)
>>> On 11.05.11 at 04:30, Shriram Rajagopalan <rshriram@cs.ubc.ca> 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:[<ffff82c48014dd57>] 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) [<ffff82c48014dd57>] arch_get_info_guest+0x5f7/0x7b0 > (XEN) [<ffff82c48010351f>] do_domctl+0x10ad/0x195e > (XEN) [<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( 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? 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Shriram Rajagopalan
2011-May-11 18:37 UTC
Re: xl/xm save -c fails - set_vcpucontext EOPNOTSUPP (was Re: [Xen-devel] xl save -c issues with Windows 7 Ultimate)
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> 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:[<ffff82c48014dd57>] 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) [<ffff82c48014dd57>] arch_get_info_guest+0x5f7/0x7b0 > > (XEN) [<ffff82c48010351f>] do_domctl+0x10ad/0x195e > > (XEN) [<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( > 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 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 > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Shriram Rajagopalan
2011-May-11 19:50 UTC
Re: xl/xm save -c fails - set_vcpucontext EOPNOTSUPP (was Re: [Xen-devel] xl save -c issues with Windows 7 Ultimate)
On Wed, May 11, 2011 at 1:37 PM, Shriram Rajagopalan <rshriram@cs.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> 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:[<ffff82c48014dd57>] 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) [<ffff82c48014dd57>] arch_get_info_guest+0x5f7/0x7b0 >> > (XEN) [<ffff82c48010351f>] do_domctl+0x10ad/0x195e >> > (XEN) [<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( >> 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 copiedverbatim 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 >> >> >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2011-May-12 08:10 UTC
Re: xl/xm save -c fails - set_vcpucontext EOPNOTSUPP (was Re: [Xen-devel] xl save -c issues with Windows 7 Ultimate)
On 11/05/2011 08:47, "Jan Beulich" <JBeulich@novell.com> wrote:> 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?Hm, I think overall we just need to get the error-path handling in this function correct. I think it''ll be a bit ugly to kludge around that. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jan Beulich
2011-May-13 10:00 UTC
Re: xl/xm save -c fails - set_vcpucontext EOPNOTSUPP (was Re: [Xen-devel] xl save -c issues with Windows 7 Ultimate)
>>> On 11.05.11 at 21:50, Shriram Rajagopalan <rshriram@cs.ubc.ca> wrote: > 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_guestThe problem really is that ->ctrlreg[3] (and also ->ctrlreg[1]) aren''t really being kept up-to-date while the domain is running (they get written only from arch_set_info_guest()), and as such we could (should?) actually delete these fields, to not confuse people (like me in this case). Here''s another shot at it: --- 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); @@ -863,10 +872,25 @@ int arch_set_info_guest( } else { - bool_t fail = v->arch.pv_vcpu.ctrlreg[3] != c(ctrlreg[3]); + unsigned long pfn = pagetable_get_pfn(v->arch.guest_table); + bool_t fail; + if ( !compat ) + { + fail = xen_pfn_to_cr3(pfn) != c.nat->ctrlreg[3]; #ifdef CONFIG_X86_64 - fail |= v->arch.pv_vcpu.ctrlreg[1] != c(ctrlreg[1]); + if ( pagetable_is_null(v->arch.guest_table_user) ) + fail |= c.nat->ctrlreg[1] || !(flags & VGCF_in_kernel); + else + { + pfn = pagetable_get_pfn(v->arch.guest_table_user); + fail |= xen_pfn_to_cr3(pfn) != c.nat->ctrlreg[1]; + } +#endif + } +#ifdef CONFIG_COMPAT + else + fail = compat_pfn_to_cr3(pfn) != c.cmp->ctrlreg[3]; #endif for ( i = 0; i < ARRAY_SIZE(v->arch.pv_vcpu.gdt_frames); ++i ) @@ -907,15 +931,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); Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Shriram Rajagopalan
2011-May-14 22:15 UTC
Re: xl/xm save -c fails - set_vcpucontext EOPNOTSUPP (was Re: [Xen-devel] xl save -c issues with Windows 7 Ultimate)
On Fri, May 13, 2011 at 6:00 AM, Jan Beulich <JBeulich@novell.com> wrote:> >>> On 11.05.11 at 21:50, Shriram Rajagopalan <rshriram@cs.ubc.ca> wrote: > > 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 > > The problem really is that ->ctrlreg[3] (and also ->ctrlreg[1]) aren''t > really being kept up-to-date while the domain is running (they get > written only from arch_set_info_guest()), and as such we could > (should?) actually delete these fields, to not confuse people (like > me in this case). > > Here''s another shot at it: > > --- 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); > @@ -863,10 +872,25 @@ int arch_set_info_guest( > } > else > { > - bool_t fail = v->arch.pv_vcpu.ctrlreg[3] != c(ctrlreg[3]); > + unsigned long pfn = pagetable_get_pfn(v->arch.guest_table); > + bool_t fail; > > + if ( !compat ) > + { > + fail = xen_pfn_to_cr3(pfn) != c.nat->ctrlreg[3]; > #ifdef CONFIG_X86_64 > - fail |= v->arch.pv_vcpu.ctrlreg[1] != c(ctrlreg[1]); > + if ( pagetable_is_null(v->arch.guest_table_user) ) > + fail |= c.nat->ctrlreg[1] || !(flags & VGCF_in_kernel); > + else > + { > + pfn = pagetable_get_pfn(v->arch.guest_table_user); > + fail |= xen_pfn_to_cr3(pfn) != c.nat->ctrlreg[1]; > + } > +#endif > + } > +#ifdef CONFIG_COMPAT > + else > + fail = compat_pfn_to_cr3(pfn) != c.cmp->ctrlreg[3]; > #endif > > for ( i = 0; i < ARRAY_SIZE(v->arch.pv_vcpu.gdt_frames); ++i ) > @@ -907,15 +931,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); > > Jan > > This one works only for 64-bit domUs. 32bit domU (on 64bit dom0) fails withusual EOPNOTSUPP. shriram _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jan Beulich
2011-May-16 12:02 UTC
Re: xl/xm save -c fails - set_vcpucontext EOPNOTSUPP (was Re: [Xen-devel] xl save -c issues with Windows 7 Ultimate)
>>> On 15.05.11 at 00:15, Shriram Rajagopalan <rshriram@cs.ubc.ca> wrote: > This one works only for 64-bit domUs. 32bit domU (on 64bit dom0) fails with > usual EOPNOTSUPP.Next (hopefully final) try below. Jan --- 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); @@ -863,11 +872,27 @@ int arch_set_info_guest( } else { - bool_t fail = v->arch.pv_vcpu.ctrlreg[3] != c(ctrlreg[3]); + unsigned long pfn = pagetable_get_pfn(v->arch.guest_table); + bool_t fail; + if ( !compat ) + { + fail = xen_pfn_to_cr3(pfn) != c.nat->ctrlreg[3]; #ifdef CONFIG_X86_64 - fail |= v->arch.pv_vcpu.ctrlreg[1] != c(ctrlreg[1]); + if ( pagetable_is_null(v->arch.guest_table_user) ) + fail |= c.nat->ctrlreg[1] || !(flags & VGCF_in_kernel); + else + { + pfn = pagetable_get_pfn(v->arch.guest_table_user); + fail |= xen_pfn_to_cr3(pfn) != c.nat->ctrlreg[1]; + } + } else { + l4_pgentry_t *l4tab = __va(pfn_to_paddr(pfn)); + + pfn = l4e_get_pfn(*l4tab); + fail = compat_pfn_to_cr3(pfn) != c.cmp->ctrlreg[3]; #endif + } for ( i = 0; i < ARRAY_SIZE(v->arch.pv_vcpu.gdt_frames); ++i ) fail |= v->arch.pv_vcpu.gdt_frames[i] != c(gdt_frames[i]); @@ -907,15 +932,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); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Shriram Rajagopalan
2011-May-17 01:48 UTC
Re: xl/xm save -c fails - set_vcpucontext EOPNOTSUPP (was Re: [Xen-devel] xl save -c issues with Windows 7 Ultimate)
On Mon, May 16, 2011 at 8:02 AM, Jan Beulich <JBeulich@novell.com> wrote:> >>> On 15.05.11 at 00:15, Shriram Rajagopalan <rshriram@cs.ubc.ca> wrote: > > This one works only for 64-bit domUs. 32bit domU (on 64bit dom0) fails > with > > usual EOPNOTSUPP. > > Next (hopefully final) try below. > > Jan > > --- 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); > @@ -863,11 +872,27 @@ int arch_set_info_guest( > } > else > { > - bool_t fail = v->arch.pv_vcpu.ctrlreg[3] != c(ctrlreg[3]); > + unsigned long pfn = pagetable_get_pfn(v->arch.guest_table); > + bool_t fail; > > + if ( !compat ) > + { > + fail = xen_pfn_to_cr3(pfn) != c.nat->ctrlreg[3]; > #ifdef CONFIG_X86_64 > - fail |= v->arch.pv_vcpu.ctrlreg[1] != c(ctrlreg[1]); > + if ( pagetable_is_null(v->arch.guest_table_user) ) > + fail |= c.nat->ctrlreg[1] || !(flags & VGCF_in_kernel); > + else > + { > + pfn = pagetable_get_pfn(v->arch.guest_table_user); > + fail |= xen_pfn_to_cr3(pfn) != c.nat->ctrlreg[1]; > + } > + } else { > + l4_pgentry_t *l4tab = __va(pfn_to_paddr(pfn)); > + > + pfn = l4e_get_pfn(*l4tab); > + fail = compat_pfn_to_cr3(pfn) != c.cmp->ctrlreg[3]; > #endif > + } > > for ( i = 0; i < ARRAY_SIZE(v->arch.pv_vcpu.gdt_frames); ++i ) > fail |= v->arch.pv_vcpu.gdt_frames[i] != c(gdt_frames[i]); > @@ -907,15 +932,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); > > > ok. this one works :). I ve tested with remus too :P. Can you please pleasespin out a patch to be pushed into the repo ? thanks for the help. shriram _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
AP Xen
2011-May-24 19:24 UTC
Re: xl/xm save -c fails - set_vcpucontext EOPNOTSUPP (was Re: [Xen-devel] xl save -c issues with Windows 7 Ultimate)
Is is possible for this (23348:3e8e1800d472) to be included in Xen 4.1.1? Thanks, AP On Mon, May 16, 2011 at 6:48 PM, Shriram Rajagopalan <rshriram@cs.ubc.ca> wrote:> On Mon, May 16, 2011 at 8:02 AM, Jan Beulich <JBeulich@novell.com> wrote: >> >> >>> On 15.05.11 at 00:15, Shriram Rajagopalan <rshriram@cs.ubc.ca> wrote: >> > This one works only for 64-bit domUs. 32bit domU (on 64bit dom0) fails >> > with >> > usual EOPNOTSUPP. >> >> Next (hopefully final) try below. >> >> Jan >> >> --- 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); >> @@ -863,11 +872,27 @@ int arch_set_info_guest( >> } >> else >> { >> - bool_t fail = v->arch.pv_vcpu.ctrlreg[3] != c(ctrlreg[3]); >> + unsigned long pfn = pagetable_get_pfn(v->arch.guest_table); >> + bool_t fail; >> >> + if ( !compat ) >> + { >> + fail = xen_pfn_to_cr3(pfn) != c.nat->ctrlreg[3]; >> #ifdef CONFIG_X86_64 >> - fail |= v->arch.pv_vcpu.ctrlreg[1] != c(ctrlreg[1]); >> + if ( pagetable_is_null(v->arch.guest_table_user) ) >> + fail |= c.nat->ctrlreg[1] || !(flags & VGCF_in_kernel); >> + else >> + { >> + pfn = pagetable_get_pfn(v->arch.guest_table_user); >> + fail |= xen_pfn_to_cr3(pfn) != c.nat->ctrlreg[1]; >> + } >> + } else { >> + l4_pgentry_t *l4tab = __va(pfn_to_paddr(pfn)); >> + >> + pfn = l4e_get_pfn(*l4tab); >> + fail = compat_pfn_to_cr3(pfn) != c.cmp->ctrlreg[3]; >> #endif >> + } >> >> for ( i = 0; i < ARRAY_SIZE(v->arch.pv_vcpu.gdt_frames); ++i ) >> fail |= v->arch.pv_vcpu.gdt_frames[i] != c(gdt_frames[i]); >> @@ -907,15 +932,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); >> >> > ok. this one works :). I ve tested with remus too :P. Can you please please > spin out a patch to be pushed into the repo ? thanks for the help. > > shriram > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2011-May-24 20:09 UTC
Re: xl/xm save -c fails - set_vcpucontext EOPNOTSUPP (was Re: [Xen-devel] xl save -c issues with Windows 7 Ultimate)
It depends on c/s 23142, and I think it isn''t even needed in the absence of that other patch. -- Keir On 24/05/2011 20:24, "AP Xen" <apxeng@gmail.com> wrote:> Is is possible for this (23348:3e8e1800d472) to be included in Xen 4.1.1? > > Thanks, > AP > > On Mon, May 16, 2011 at 6:48 PM, Shriram Rajagopalan <rshriram@cs.ubc.ca> > wrote: >> On Mon, May 16, 2011 at 8:02 AM, Jan Beulich <JBeulich@novell.com> wrote: >>> >>>>>> On 15.05.11 at 00:15, Shriram Rajagopalan <rshriram@cs.ubc.ca> wrote: >>>> This one works only for 64-bit domUs. 32bit domU (on 64bit dom0) fails >>>> with >>>> usual EOPNOTSUPP. >>> >>> Next (hopefully final) try below. >>> >>> Jan >>> >>> --- 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); >>> @@ -863,11 +872,27 @@ int arch_set_info_guest( >>> } >>> else >>> { >>> - bool_t fail = v->arch.pv_vcpu.ctrlreg[3] != c(ctrlreg[3]); >>> + unsigned long pfn = pagetable_get_pfn(v->arch.guest_table); >>> + bool_t fail; >>> >>> + if ( !compat ) >>> + { >>> + fail = xen_pfn_to_cr3(pfn) != c.nat->ctrlreg[3]; >>> #ifdef CONFIG_X86_64 >>> - fail |= v->arch.pv_vcpu.ctrlreg[1] != c(ctrlreg[1]); >>> + if ( pagetable_is_null(v->arch.guest_table_user) ) >>> + fail |= c.nat->ctrlreg[1] || !(flags & VGCF_in_kernel); >>> + else >>> + { >>> + pfn = pagetable_get_pfn(v->arch.guest_table_user); >>> + fail |= xen_pfn_to_cr3(pfn) != c.nat->ctrlreg[1]; >>> + } >>> + } else { >>> + l4_pgentry_t *l4tab = __va(pfn_to_paddr(pfn)); >>> + >>> + pfn = l4e_get_pfn(*l4tab); >>> + fail = compat_pfn_to_cr3(pfn) != c.cmp->ctrlreg[3]; >>> #endif >>> + } >>> >>> for ( i = 0; i < ARRAY_SIZE(v->arch.pv_vcpu.gdt_frames); ++i ) >>> fail |= v->arch.pv_vcpu.gdt_frames[i] != c(gdt_frames[i]); >>> @@ -907,15 +932,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); >>> >>> >> ok. this one works :). I ve tested with remus too :P. Can you please please >> spin out a patch to be pushed into the repo ? thanks for the help. >> >> shriram >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel >> >>_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jan Beulich
2011-May-25 07:15 UTC
Re: xl/xm save -c fails - set_vcpucontext EOPNOTSUPP (was Re: [Xen-devel] xl save -c issues with Windows 7 Ultimate)
>>> On 24.05.11 at 22:09, Keir Fraser <keir.xen@gmail.com> wrote: > It depends on c/s 23142, and I think it isn''t even needed in the absence of > that other patch.Correct - no checking on the context was done up to 23142, so as long as that one doesn''t get backported the fix to it obviously doesn''t need to be either. It''s odd in the first place that you''re asking, as it sort of implies you''ve been seeing -EOPNOTSUPP problems on 4.1, which you''d need to explain/investigate independently of the problem addressed here. Jan> -- Keir > > On 24/05/2011 20:24, "AP Xen" <apxeng@gmail.com> wrote: > >> Is is possible for this (23348:3e8e1800d472) to be included in Xen 4.1.1? >> >> Thanks, >> AP >> >> On Mon, May 16, 2011 at 6:48 PM, Shriram Rajagopalan <rshriram@cs.ubc.ca> >> wrote: >>> On Mon, May 16, 2011 at 8:02 AM, Jan Beulich <JBeulich@novell.com> wrote: >>>> >>>>>>> On 15.05.11 at 00:15, Shriram Rajagopalan <rshriram@cs.ubc.ca> wrote: >>>>> This one works only for 64-bit domUs. 32bit domU (on 64bit dom0) fails >>>>> with >>>>> usual EOPNOTSUPP. >>>> >>>> Next (hopefully final) try below. >>>> >>>> Jan >>>> >>>> --- 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); >>>> @@ -863,11 +872,27 @@ int arch_set_info_guest( >>>> } >>>> else >>>> { >>>> - bool_t fail = v->arch.pv_vcpu.ctrlreg[3] != c(ctrlreg[3]); >>>> + unsigned long pfn = pagetable_get_pfn(v->arch.guest_table); >>>> + bool_t fail; >>>> >>>> + if ( !compat ) >>>> + { >>>> + fail = xen_pfn_to_cr3(pfn) != c.nat->ctrlreg[3]; >>>> #ifdef CONFIG_X86_64 >>>> - fail |= v->arch.pv_vcpu.ctrlreg[1] != c(ctrlreg[1]); >>>> + if ( pagetable_is_null(v->arch.guest_table_user) ) >>>> + fail |= c.nat->ctrlreg[1] || !(flags & VGCF_in_kernel); >>>> + else >>>> + { >>>> + pfn = pagetable_get_pfn(v->arch.guest_table_user); >>>> + fail |= xen_pfn_to_cr3(pfn) != c.nat->ctrlreg[1]; >>>> + } >>>> + } else { >>>> + l4_pgentry_t *l4tab = __va(pfn_to_paddr(pfn)); >>>> + >>>> + pfn = l4e_get_pfn(*l4tab); >>>> + fail = compat_pfn_to_cr3(pfn) != c.cmp->ctrlreg[3]; >>>> #endif >>>> + } >>>> >>>> for ( i = 0; i < ARRAY_SIZE(v->arch.pv_vcpu.gdt_frames); ++i ) >>>> fail |= v->arch.pv_vcpu.gdt_frames[i] != c(gdt_frames[i]); >>>> @@ -907,15 +932,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); >>>> >>>> >>> ok. this one works :). I ve tested with remus too :P. Can you please please >>> spin out a patch to be pushed into the repo ? thanks for the help. >>> >>> shriram >>> >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xensource.com >>> http://lists.xensource.com/xen-devel >>> >>>_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
AP Xen
2011-May-25 07:53 UTC
Re: xl/xm save -c fails - set_vcpucontext EOPNOTSUPP (was Re: [Xen-devel] xl save -c issues with Windows 7 Ultimate)
On Wed, May 25, 2011 at 12:15 AM, Jan Beulich <JBeulich@novell.com> wrote:>>>> On 24.05.11 at 22:09, Keir Fraser <keir.xen@gmail.com> wrote: >> It depends on c/s 23142, and I think it isn''t even needed in the absence of >> that other patch. > > Correct - no checking on the context was done up to 23142, so as > long as that one doesn''t get backported the fix to it obviously doesn''t > need to be either. > > It''s odd in the first place that you''re asking, as it sort of implies you''ve > been seeing -EOPNOTSUPP problems on 4.1, which you''d need to > explain/investigate independently of the problem addressed here.You are right. I lost site of my original problem which is xl save -c not working with 4.1. I did a quick get_vcpucontext and set_vcpucontext test with a HVM domain and that seems to work without any issues. So I think the root cause of the -c option not working is something else. AP> Jan > >> -- Keir >> >> On 24/05/2011 20:24, "AP Xen" <apxeng@gmail.com> wrote: >> >>> Is is possible for this (23348:3e8e1800d472) to be included in Xen 4.1.1? >>> >>> Thanks, >>> AP >>> >>> On Mon, May 16, 2011 at 6:48 PM, Shriram Rajagopalan <rshriram@cs.ubc.ca> >>> wrote: >>>> On Mon, May 16, 2011 at 8:02 AM, Jan Beulich <JBeulich@novell.com> wrote: >>>>> >>>>>>>> On 15.05.11 at 00:15, Shriram Rajagopalan <rshriram@cs.ubc.ca> wrote: >>>>>> This one works only for 64-bit domUs. 32bit domU (on 64bit dom0) fails >>>>>> with >>>>>> usual EOPNOTSUPP. >>>>> >>>>> Next (hopefully final) try below. >>>>> >>>>> Jan >>>>> >>>>> --- 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); >>>>> @@ -863,11 +872,27 @@ int arch_set_info_guest( >>>>> } >>>>> else >>>>> { >>>>> - bool_t fail = v->arch.pv_vcpu.ctrlreg[3] != c(ctrlreg[3]); >>>>> + unsigned long pfn = pagetable_get_pfn(v->arch.guest_table); >>>>> + bool_t fail; >>>>> >>>>> + if ( !compat ) >>>>> + { >>>>> + fail = xen_pfn_to_cr3(pfn) != c.nat->ctrlreg[3]; >>>>> #ifdef CONFIG_X86_64 >>>>> - fail |= v->arch.pv_vcpu.ctrlreg[1] != c(ctrlreg[1]); >>>>> + if ( pagetable_is_null(v->arch.guest_table_user) ) >>>>> + fail |= c.nat->ctrlreg[1] || !(flags & VGCF_in_kernel); >>>>> + else >>>>> + { >>>>> + pfn = pagetable_get_pfn(v->arch.guest_table_user); >>>>> + fail |= xen_pfn_to_cr3(pfn) != c.nat->ctrlreg[1]; >>>>> + } >>>>> + } else { >>>>> + l4_pgentry_t *l4tab = __va(pfn_to_paddr(pfn)); >>>>> + >>>>> + pfn = l4e_get_pfn(*l4tab); >>>>> + fail = compat_pfn_to_cr3(pfn) != c.cmp->ctrlreg[3]; >>>>> #endif >>>>> + } >>>>> >>>>> for ( i = 0; i < ARRAY_SIZE(v->arch.pv_vcpu.gdt_frames); ++i ) >>>>> fail |= v->arch.pv_vcpu.gdt_frames[i] != c(gdt_frames[i]); >>>>> @@ -907,15 +932,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); >>>>> >>>>> >>>> ok. this one works :). I ve tested with remus too :P. Can you please please >>>> spin out a patch to be pushed into the repo ? thanks for the help. >>>> >>>> shriram >>>> >>>> _______________________________________________ >>>> Xen-devel mailing list >>>> Xen-devel@lists.xensource.com >>>> http://lists.xensource.com/xen-devel >>>> >>>> > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel