Hi, I''ve been trying to figure out why my copy of s10u9 did not run PV drivers when I installed it on Xen 4.1 when it was perfectly happy on Xen 3.4... It turns out that the kernel is making a check that the maximal Xen CPUID leaf is no greater than base + 2. This was true on Xen 3.4 but when the PVRDTSCP patch was added it ceased to be true with the addition of the cpuid_time_leaf code. Clearly future versions of the Solaris kernel should revise this check but to allow this kernel to enable PV drivers I was wondering what sort of workaround could be done. My current thoughts are along the lines of disabling the extra CPUID leaf if tsc_mode is < TSC_MODE_PVRDTSCP. An alternative might be to introduce another tsc_mode that specifically causes the leaf to be obscured. Thoughts? Paul _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 01/07/2011 18:02, "Paul Durrant" <Paul.Durrant@citrix.com> wrote:> Hi, > > I''ve been trying to figure out why my copy of s10u9 did not run PV drivers > when I installed it on Xen 4.1 when it was perfectly happy on Xen 3.4... > > It turns out that the kernel is making a check that the maximal Xen CPUID > leaf is no greater than base + 2. This was true on Xen 3.4 but when the > PVRDTSCP patch was added it ceased to be true with the addition of the > cpuid_time_leaf code. > Clearly future versions of the Solaris kernel should revise this check but > to allow this kernel to enable PV drivers I was wondering what sort of > workaround could be done. My current thoughts are along the lines of disabling > the extra CPUID leaf if tsc_mode is < TSC_MODE_PVRDTSCP. An alternative might > be to introduce another tsc_mode that specifically causes the leaf to be > obscured. Thoughts?We might add other leaves in future. Best might be a domctl to restrict max leaf per domain, and do all the relevant plumbing of that through toolstacks. Fun. -- Keir> Paul > > _______________________________________________ > 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
I was afraid you might say that :-/ Ta, Paul> -----Original Message----- > From: Keir Fraser [mailto:keir.xen@gmail.com] > Sent: 01 July 2011 18:19 > To: Paul Durrant; xen-devel@lists.xensource.com > Cc: Dan Magenheimer > Subject: Re: [Xen-devel] Solaris and PVRDTSCP > > On 01/07/2011 18:02, "Paul Durrant" <Paul.Durrant@citrix.com> wrote: > > > Hi, > > > > I''ve been trying to figure out why my copy of s10u9 did not run > PV > > drivers when I installed it on Xen 4.1 when it was perfectly happy > on Xen 3.4... > > > > It turns out that the kernel is making a check that the maximal > Xen > > CPUID leaf is no greater than base + 2. This was true on Xen 3.4 > but > > when the PVRDTSCP patch was added it ceased to be true with the > > addition of the cpuid_time_leaf code. > > Clearly future versions of the Solaris kernel should revise this > > check but to allow this kernel to enable PV drivers I was > wondering > > what sort of workaround could be done. My current thoughts are > along > > the lines of disabling the extra CPUID leaf if tsc_mode is < > > TSC_MODE_PVRDTSCP. An alternative might be to introduce another > > tsc_mode that specifically causes the leaf to be obscured. > Thoughts? > > We might add other leaves in future. Best might be a domctl to > restrict max leaf per domain, and do all the relevant plumbing of > that through toolstacks. Fun. > > -- Keir > > > Paul > > > > _______________________________________________ > > 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
Hi Paul --> From: Paul Durrant [mailto:Paul.Durrant@citrix.com] > Cc: Dan Magenheimer > Subject: Solaris and PVRDTSCP > > Hi, > > I''ve been trying to figure out why my copy of s10u9 did not run PV drivers when I installed it on > Xen 4.1 when it was perfectly happy on Xen 3.4... > > It turns out that the kernel is making a check that the maximal Xen CPUID leaf is no greater than > base + 2. This was true on Xen 3.4 but when the PVRDTSCP patch was added it ceased to be true with the > addition of the cpuid_time_leaf code.What happens? Belly up? Why is this only on PV drivers rather than pure HVM?> Clearly future versions of the Solaris kernel should revise this check but to allow this kernel to > enable PV drivers I was wondering what sort of workaround could be done. My current thoughts are along > the lines of disabling the extra CPUID leaf if tsc_mode is < TSC_MODE_PVRDTSCP.This seems reasonable. The info on that leaf could be useful in other modes, but likely hasn''t been.> An alternative might > be to introduce another tsc_mode that specifically causes the leaf to be obscured. Thoughts? > > Paul_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 01/07/2011 18:51, "Dan Magenheimer" <dan.magenheimer@oracle.com> wrote:>> Clearly future versions of the Solaris kernel should revise this check but >> to allow this kernel to >> enable PV drivers I was wondering what sort of workaround could be done. My >> current thoughts are along >> the lines of disabling the extra CPUID leaf if tsc_mode is < >> TSC_MODE_PVRDTSCP. > > This seems reasonable. The info on that leaf could be useful in other > modes, but likely hasn''t been.Tbh I''m fine with this as well, on the understanding that it may end up having to be fixed the hard way (explicit max_leaf) if we add anything more to the hypervisor cpuid space. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> -----Original Message----- > From: Dan Magenheimer [mailto:dan.magenheimer@oracle.com] > Sent: 01 July 2011 18:51 > To: Paul Durrant; xen-devel@lists.xensource.com > Subject: RE: Solaris and PVRDTSCP > > Hi Paul -- > > > From: Paul Durrant [mailto:Paul.Durrant@citrix.com] > > Cc: Dan Magenheimer > > Subject: Solaris and PVRDTSCP > > > > Hi, > > > > I''ve been trying to figure out why my copy of s10u9 did not run > PV > > drivers when I installed it on Xen 4.1 when it was perfectly happy > on Xen 3.4... > > > > It turns out that the kernel is making a check that the maximal > Xen > > CPUID leaf is no greater than base + 2. This was true on Xen 3.4 > but > > when the PVRDTSCP patch was added it ceased to be true with the > addition of the cpuid_time_leaf code. > > What happens? Belly up? Why is this only on PV drivers rather than > pure HVM? >No, it doesn''t go belly up, You just don''t get PV drivers, you get emulated instead. As for why the check is there? No idea.> > Clearly future versions of the Solaris kernel should revise this > > check but to allow this kernel to enable PV drivers I was > wondering > > what sort of workaround could be done. My current thoughts are > along the lines of disabling the extra CPUID leaf if tsc_mode is < > TSC_MODE_PVRDTSCP. > > This seems reasonable. The info on that leaf could be useful in > other modes, but likely hasn''t been. > > > An alternative might > > be to introduce another tsc_mode that specifically causes the leaf > to be obscured. Thoughts? > > > > Paul_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Cool. I''ll go with the simple approach for now then :-) Paul> -----Original Message----- > From: Keir Fraser [mailto:keir.xen@gmail.com] > Sent: 01 July 2011 19:04 > To: Dan Magenheimer; Paul Durrant; xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] RE: Solaris and PVRDTSCP > > On 01/07/2011 18:51, "Dan Magenheimer" <dan.magenheimer@oracle.com> > wrote: > > >> Clearly future versions of the Solaris kernel should revise > this > >> check but to allow this kernel to enable PV drivers I was > wondering > >> what sort of workaround could be done. My current thoughts are > along > >> the lines of disabling the extra CPUID leaf if tsc_mode is < > >> TSC_MODE_PVRDTSCP. > > > > This seems reasonable. The info on that leaf could be useful in > other > > modes, but likely hasn''t been. > > Tbh I''m fine with this as well, on the understanding that it may end > up having to be fixed the hard way (explicit max_leaf) if we add > anything more to the hypervisor cpuid space. > > -- Keir >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel