In "arch/x86/hvm/vmx/vmx.c", vmx_update_guest_cr(), the CR0.WP is
always
set as following code:
v->arch.hvm_vcpu.hw_cr[0] v->arch.hvm_vcpu.guest_cr[0]
|
X86_CR0_PE | X86_CR0_NE | X86_CR0_PG | X86_CR0_WP;
I''m wondering are there any special reason for this? I try to check
shadow code and didn''t find any clue.
Can anyone give me some hints?
Thanks
Yunhong Jiang
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
It''s necessary because we need to trap guest writes to pagetables, regardless of setting of guest CR0.WP. If it turns out we need to properly emulate CR0.WP then we''ll need to come up with a scheme that does not require us to run the guest with real CR0.WP set. Possibly it will require us to emulate certain memory accesses. -- Keir On 8/11/07 14:23, "Jiang, Yunhong" <yunhong.jiang@intel.com> wrote:> In "arch/x86/hvm/vmx/vmx.c", vmx_update_guest_cr(), the CR0.WP is always > set as following code: > v->arch.hvm_vcpu.hw_cr[0] > v->arch.hvm_vcpu.guest_cr[0] | > X86_CR0_PE | X86_CR0_NE | X86_CR0_PG | X86_CR0_WP; > > I''m wondering are there any special reason for this? I try to check > shadow code and didn''t find any clue. > Can anyone give me some hints? > > Thanks > Yunhong Jiang > > _______________________________________________ > 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
Jiang, Yunhong
2007-Nov-08 14:57 UTC
RE: [Xen-devel] Why CR0.WP is always set in HVM domain
Thanks for your explaination. I notice some anti-virus application clear CR0.WP, so maybe we need to consider this support. -- Yunhong xen-devel-bounces@lists.xensource.com <> wrote:> It''s necessary because we need to trap guest writes to pagetables, > regardless of setting of guest CR0.WP. If it turns out we need > to properly > emulate CR0.WP then we''ll need to come up with a scheme that does not > require us to run the guest with real CR0.WP set. Possibly it > will require > us to emulate certain memory accesses. > > -- Keir > > On 8/11/07 14:23, "Jiang, Yunhong" <yunhong.jiang@intel.com> wrote: > >> In "arch/x86/hvm/vmx/vmx.c", vmx_update_guest_cr(), the CR0.WP isalways>> set as following code: v->arch.hvm_vcpu.hw_cr[0] >> v->arch.hvm_vcpu.guest_cr[0] | >> X86_CR0_PE | X86_CR0_NE | X86_CR0_PG | X86_CR0_WP; >> >> I''m wondering are there any special reason for this? I try to check >> shadow code and didn''t find any clue. >> Can anyone give me some hints? >> >> Thanks >> Yunhong Jiang >> >> _______________________________________________ >> 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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
To set cr0.wp is to prevent supervisor writing into read-only memory protected
by page directory/page table entry.
I remember some old x86 processor (i.e. 486) didn''t have wp bit at cr0.
At that time, supervisor can write into even read-only memory.
To add wp bit at cr0 is to support copy-on-write technology of UNIX.
Regards,
Jinsong
-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Jiang, Yunhong
Sent: 2007年11月8日 22:23
To: xen-devel@lists.xensource.com; Tim Deegan
Subject: [Xen-devel] Why CR0.WP is always set in HVM domain
In "arch/x86/hvm/vmx/vmx.c", vmx_update_guest_cr(), the CR0.WP is
always
set as following code:
v->arch.hvm_vcpu.hw_cr[0] v->arch.hvm_vcpu.guest_cr[0]
|
X86_CR0_PE | X86_CR0_NE | X86_CR0_PG | X86_CR0_WP;
I''m wondering are there any special reason for this? I try to check
shadow code and didn''t find any clue.
Can anyone give me some hints?
Thanks
Yunhong Jiang
_______________________________________________
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
Jiang, Yunhong
2007-Nov-08 17:25 UTC
RE: [Xen-devel] Why CR0.WP is always set in HVM domain
Not sure if we can use shadow_mode_trap_reads(), i.e. when WP is clear, we set all user space mapping to guest page table to be non-present. And then do emulate in shadow for such situation. But seems shadow_mode_traps_reads not implemented yet :( -- Yunhong xen-devel-bounces@lists.xensource.com <> wrote:> Thanks for your explaination. > I notice some anti-virus application clear CR0.WP, so maybe we need to > consider this support. > > -- Yunhong > > xen-devel-bounces@lists.xensource.com <> wrote: >> It''s necessary because we need to trap guest writes to pagetables, >> regardless of setting of guest CR0.WP. If it turns out we need >> to properly >> emulate CR0.WP then we''ll need to come up with a scheme that does not >> require us to run the guest with real CR0.WP set. Possibly it >> will require >> us to emulate certain memory accesses. >> >> -- Keir >> >> On 8/11/07 14:23, "Jiang, Yunhong" <yunhong.jiang@intel.com> wrote: >> >>> In "arch/x86/hvm/vmx/vmx.c", vmx_update_guest_cr(), the CR0.WP isalways>>> set as following code: v->arch.hvm_vcpu.hw_cr[0] >>> v->arch.hvm_vcpu.guest_cr[0] | >>> X86_CR0_PE | X86_CR0_NE | X86_CR0_PG | X86_CR0_WP; >>> >>> I''m wondering are there any special reason for this? I try to check >>> shadow code and didn''t find any clue. >>> Can anyone give me some hints? >>> >>> Thanks >>> Yunhong Jiang >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > 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
That might work. There are other cases where pages need to be read-only for the guest of course (e.g., live migration dirty-page logging). It might be better just to emulate CR0.WP than fix up all the places where must-be-read-only pages would unfortunately become writable. -- Keir On 8/11/07 17:25, "Jiang, Yunhong" <yunhong.jiang@intel.com> wrote:> Not sure if we can use shadow_mode_trap_reads(), i.e. when WP is clear, > we set all user space mapping to guest page table to be non-present. And > then do emulate in shadow for such situation. But seems > shadow_mode_traps_reads not implemented yet :( > > -- Yunhong > > > xen-devel-bounces@lists.xensource.com <> wrote: >> Thanks for your explaination. >> I notice some anti-virus application clear CR0.WP, so maybe we need to >> consider this support. >> >> -- Yunhong >> >> xen-devel-bounces@lists.xensource.com <> wrote: >>> It''s necessary because we need to trap guest writes to pagetables, >>> regardless of setting of guest CR0.WP. If it turns out we need >>> to properly >>> emulate CR0.WP then we''ll need to come up with a scheme that does not >>> require us to run the guest with real CR0.WP set. Possibly it >>> will require >>> us to emulate certain memory accesses. >>> >>> -- Keir >>> >>> On 8/11/07 14:23, "Jiang, Yunhong" <yunhong.jiang@intel.com> wrote: >>> >>>> In "arch/x86/hvm/vmx/vmx.c", vmx_update_guest_cr(), the CR0.WP is > always >>>> set as following code: v->arch.hvm_vcpu.hw_cr[0] >>>> v->arch.hvm_vcpu.guest_cr[0] | >>>> X86_CR0_PE | X86_CR0_NE | X86_CR0_PG | X86_CR0_WP; >>>> >>>> I''m wondering are there any special reason for this? I try to check >>>> shadow code and didn''t find any clue. >>>> Can anyone give me some hints? >>>> >>>> Thanks >>>> Yunhong Jiang >>>> >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ >> 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