Liu, Eric E
2007-Jul-27 08:03 UTC
[Xen-devel] [PATCH]Do some checks and settings of CR0 according to VMX capability MSRs
According to SDM Vol 3B 19.8 Software should consult the VMX capability MSRs to determine how bits in CR0 are set, VMXON fails if any of these bits contains an unsupported value. And according to SDM Vol 3A 2.5, 3B 21.3 and 2A MOV-MOV to/from Control Registers, setting upper 32 bits of CR0 results in a general-protection exception and setting the reserved bits in lower 32 bits of CR0 are ignored . In accordance with above-mentioned, the patch is attached to do some checks and settings of CR0. Signed-off-by: Eric E Liu <eric.e.liu@intel.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2007-Jul-27 08:18 UTC
Re: [Xen-devel] [PATCH]Do some checks and settings of CR0 according to VMX capability MSRs
I agree with some aspects of this patch but not others. For example, not explicitly including PG and PE in guest-mode cr0 value is a bad idea. If a future processor does support e.g., paged real mode then it won¹t magically be the case that old Xen will know how to handle that. Currently we expect and require a VMX guest always to run with CR0.PE==1. I¹ll pull out the bits of the patch that I like. -- Keir On 27/7/07 09:03, "Liu, Eric E" <eric.e.liu@intel.com> wrote:> According to SDM Vol 3B 19.8 Software should consult the VMX capability MSRs > to determine how bits > in CR0 are set, VMXON fails if any of these bits contains an unsupported > value. And according to > SDM Vol 3A 2.5, 3B 21.3 and 2A MOV-MOV to/from Control Registers, setting > upper 32 bits of CR0 > results in a general-protection exception and setting the reserved bits in > lower 32 bits of CR0 are ignored . > In accordance with above-mentioned, the patch is attached to do some checks > and settings of CR0._______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Li, Xin B
2007-Aug-01 04:50 UTC
RE: [Xen-devel] [PATCH]Do some checks and settings of CR0according to VMX capability MSRs
good point, and this is a two side issue, one is hardware capability, the other is software capability, maybe a better way is to have another CR0 value expected by software, and use both of hardware and software expected value to get the effiective one? -Xin ________________________________ From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Keir Fraser Sent: Friday, July 27, 2007 4:19 PM To: Liu, Eric E; xen-devel@lists.xensource.com Subject: Re: [Xen-devel] [PATCH]Do some checks and settings of CR0according to VMX capability MSRs I agree with some aspects of this patch but not others. For example, not explicitly including PG and PE in guest-mode cr0 value is a bad idea. If a future processor does support e.g., paged real mode then it won''t magically be the case that old Xen will know how to handle that. Currently we expect and require a VMX guest always to run with CR0.PE==1. I''ll pull out the bits of the patch that I like. -- Keir On 27/7/07 09:03, "Liu, Eric E" <eric.e.liu@intel.com> wrote: According to SDM Vol 3B 19.8 Software should consult the VMX capability MSRs to determine how bits in CR0 are set, VMXON fails if any of these bits contains an unsupported value. And according to SDM Vol 3A 2.5, 3B 21.3 and 2A MOV-MOV to/from Control Registers, setting upper 32 bits of CR0 results in a general-protection exception and setting the reserved bits in lower 32 bits of CR0 are ignored . In accordance with above-mentioned, the patch is attached to do some checks and settings of CR0. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2007-Aug-01 06:11 UTC
Re: [Xen-devel] [PATCH]Do some checks and settings of CR0according to VMX capability MSRs
Working correctly with arbitrary settings of the capabilities MSRs is clearly impossible. The real question is: what are the most likely sorts of changes in future processors? My assumption is that capabilities will increase and hence the constraints indicated by the capability MSRs will decrease. In which case we can evolve the capability-checking code over time, as Xen develops the ability to make use of new processor features (e.g., if a future version of VMX supports paged real mode). I don¹t think it is likely that constraints will increase in future (e.g., bits must be set or clear that could previously be set as you like; or even that a bit that was forced one way in one version of VMX must be set the other way in a later version). Trying to support that gracefully and well would be a total pain, and to what end? -- Keir On 1/8/07 05:50, "Li, Xin B" <xin.b.li@intel.com> wrote:> good point, and this is a two side issue, one is hardware capability, the > other is software capability, maybe a better way is to have another CR0 value > expected by software, and use both of hardware and software expected value to > get the effiective one? > -Xin > >> >> >> >> From: xen-devel-bounces@lists.xensource.com >> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Keir Fraser >> Sent: Friday, July 27, 2007 4:19 PM >> To: Liu, Eric E; xen-devel@lists.xensource.com >> Subject: Re: [Xen-devel] [PATCH]Do some checks and settings of CR0according >> to VMX capability MSRs >> >> >> I agree with some aspects of this patch but not others. For example, not >> explicitly including PG and PE in guest-mode cr0 value is a bad idea. If a >> future processor does support e.g., paged real mode then it won¹t magically >> be the case that old Xen will know how to handle that. Currently we expect >> and require a VMX guest always to run with CR0.PE==1. >> >> I¹ll pull out the bits of the patch that I like. >> >> -- Keir >> >> On 27/7/07 09:03, "Liu, Eric E" <eric.e.liu@intel.com> wrote: >> >> >>> According to SDM Vol 3B 19.8 Software should consult the VMX capability >>> MSRs to determine how bits >>> in CR0 are set, VMXON fails if any of these bits contains an unsupported >>> value. And according to >>> SDM Vol 3A 2.5, 3B 21.3 and 2A MOV-MOV to/from Control Registers, setting >>> upper 32 bits of CR0 >>> results in a general-protection exception and setting the reserved bits in >>> lower 32 bits of CR0 are ignored . >>> In accordance with above-mentioned, the patch is attached to do some checks >>> and settings of CR0. >> > > > _______________________________________________ > 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
Li, Xin B
2007-Aug-01 07:13 UTC
RE: [Xen-devel] [PATCH]Do some checks and settings ofCR0according to VMX capability MSRs
agree, we can evolve the code step by step. -Xin ________________________________ From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Keir Fraser Sent: Wednesday, August 01, 2007 2:12 PM To: Li, Xin B; Liu, Eric E; xen-devel@lists.xensource.com Subject: Re: [Xen-devel] [PATCH]Do some checks and settings ofCR0according to VMX capability MSRs Working correctly with arbitrary settings of the capabilities MSRs is clearly impossible. The real question is: what are the most likely sorts of changes in future processors? My assumption is that capabilities will increase and hence the constraints indicated by the capability MSRs will decrease. In which case we can evolve the capability-checking code over time, as Xen develops the ability to make use of new processor features (e.g., if a future version of VMX supports paged real mode). I don''t think it is likely that constraints will increase in future (e.g., bits must be set or clear that could previously be set as you like; or even that a bit that was forced one way in one version of VMX must be set the other way in a later version). Trying to support that gracefully and well would be a total pain, and to what end? -- Keir On 1/8/07 05:50, "Li, Xin B" <xin.b.li@intel.com> wrote: good point, and this is a two side issue, one is hardware capability, the other is software capability, maybe a better way is to have another CR0 value expected by software, and use both of hardware and software expected value to get the effiective one? -Xin ________________________________ From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Keir Fraser Sent: Friday, July 27, 2007 4:19 PM To: Liu, Eric E; xen-devel@lists.xensource.com Subject: Re: [Xen-devel] [PATCH]Do some checks and settings of CR0according to VMX capability MSRs I agree with some aspects of this patch but not others. For example, not explicitly including PG and PE in guest-mode cr0 value is a bad idea. If a future processor does support e.g., paged real mode then it won''t magically be the case that old Xen will know how to handle that. Currently we expect and require a VMX guest always to run with CR0.PE==1. I''ll pull out the bits of the patch that I like. -- Keir On 27/7/07 09:03, "Liu, Eric E" <eric.e.liu@intel.com> wrote: According to SDM Vol 3B 19.8 Software should consult the VMX capability MSRs to determine how bits in CR0 are set, VMXON fails if any of these bits contains an unsupported value. And according to SDM Vol 3A 2.5, 3B 21.3 and 2A MOV-MOV to/from Control Registers, setting upper 32 bits of CR0 results in a general-protection exception and setting the reserved bits in lower 32 bits of CR0 are ignored . In accordance with above-mentioned, the patch is attached to do some checks and settings of CR0. ________________________________ _______________________________________________ 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