On Mon, Feb 08, 2016 at 04:53:00PM +, Andrew Cooper wrote:
> On 08/02/16 16:45, Borislav Petkov wrote:
> > On Mon, Feb 08, 2016 at 04:38:40PM +, Andrew Cooper wrote:
> >> Does the early loader have extable support? If so, this is fairly easy
> >> to fix. If not, we have a problem.
> > It
On Mon, Feb 08, 2016 at 03:45:21PM -0500, Boris Ostrovsky wrote:
> So it looks like we can just simply revert a18a0f6850 because the very next
> patch to microcode code (fbae4ba8c4a) makes the original problem (of using
> __pa_nodebug, which we shouldn't use on PV) go away: we don't call
> load_uco
On 02/08/2016 11:52 AM, Boris Ostrovsky wrote:
On 02/08/2016 11:45 AM, Borislav Petkov wrote:
On Mon, Feb 08, 2016 at 04:38:40PM +, Andrew Cooper wrote:
Does the early loader have extable support? If so, this is fairly easy
to fix. If not, we have a problem.
It doesn't and regardless,
On Mon, Feb 08, 2016 at 04:53:00PM +, Andrew Cooper wrote:
> As an alternative check which should be doable this early on, peeking in
> the head of hypercall_page should work. If Linux was booted as a PV
> guest, the hypercall_page will have been constructed by the domain
> builder, and won't
On 02/08/2016 11:45 AM, Borislav Petkov wrote:
On Mon, Feb 08, 2016 at 04:38:40PM +, Andrew Cooper wrote:
Does the early loader have extable support? If so, this is fairly easy
to fix. If not, we have a problem.
It doesn't and regardless, you want to have this CPUID querying as
simple a
On 08/02/16 16:45, Borislav Petkov wrote:
> On Mon, Feb 08, 2016 at 04:38:40PM +, Andrew Cooper wrote:
>> Does the early loader have extable support? If so, this is fairly easy
>> to fix. If not, we have a problem.
> It doesn't and regardless, you want to have this CPUID querying as
> simple
On Mon, Feb 08, 2016 at 11:41:16AM -0500, Boris Ostrovsky wrote:
> Keep in mind that Xen PV doesn't go through startup_32|64(). It starts at
> xen_start_kernel (save for a small stub before that), which sets pvops. It
> "joins" regular/baremetal code in
> i386_start_kernel/x86_64_start_reservation
On 02/08/2016 11:35 AM, Borislav Petkov wrote:
On Mon, Feb 08, 2016 at 11:31:04AM -0500, Boris Ostrovsky wrote:
I think we are OK for PV because this code will be executed after pvops are
set and so we will be calling xen_cpuid().
Not for the early loader - it is too early for pvops then. So
On Mon, Feb 08, 2016 at 04:38:40PM +, Andrew Cooper wrote:
> Does the early loader have extable support? If so, this is fairly easy
> to fix. If not, we have a problem.
It doesn't and regardless, you want to have this CPUID querying as
simple as possible. No special handling, no special pref
On 08/02/16 16:35, Borislav Petkov wrote:
> On Mon, Feb 08, 2016 at 11:31:04AM -0500, Boris Ostrovsky wrote:
>> I think we are OK for PV because this code will be executed after pvops are
>> set and so we will be calling xen_cpuid().
> Not for the early loader - it is too early for pvops then. So y
On Mon, Feb 08, 2016 at 11:31:04AM -0500, Boris Ostrovsky wrote:
> I think we are OK for PV because this code will be executed after pvops are
> set and so we will be calling xen_cpuid().
Not for the early loader - it is too early for pvops then. So you're
saying something like that won't work?
-
On 08/02/16 16:31, Boris Ostrovsky wrote:
>
>
> On 02/08/2016 11:26 AM, Andrew Cooper wrote:
>> On 08/02/16 16:12, Boris Ostrovsky wrote:
>>>
>>> On 02/08/2016 11:05 AM, Andrew Cooper wrote:
For compatibility with other virtualisation specs, Xen's cpuid leaves
shift depending on configura
On 02/08/2016 11:26 AM, Andrew Cooper wrote:
On 08/02/16 16:12, Boris Ostrovsky wrote:
On 02/08/2016 11:05 AM, Andrew Cooper wrote:
For compatibility with other virtualisation specs, Xen's cpuid leaves
shift depending on configuration.
Spec at
http://xenbits.xen.org/gitweb/?p=xen.git;a=blob
On 08/02/16 16:12, Boris Ostrovsky wrote:
>
>
> On 02/08/2016 11:05 AM, Andrew Cooper wrote:
>>
>> For compatibility with other virtualisation specs, Xen's cpuid leaves
>> shift depending on configuration.
>>
>> Spec at
>> http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/arch-x8
On 02/08/2016 11:05 AM, Andrew Cooper wrote:
For compatibility with other virtualisation specs, Xen's cpuid leaves
shift depending on configuration.
Spec at
http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/arch-x86/cpuid.h;h=d709340f18d089560b959835eabb7b6609542c7e;hb=HEAD
On 08/02/16 15:55, Borislav Petkov wrote:
> On Mon, Feb 08, 2016 at 10:39:43AM -0500, Boris Ostrovsky wrote:
>> It does. Very much IIRC, the problem was not caused by an access to MSR but
>> rather some sort of address not being available somewhere.
> See below.
>
>>> - microcode application on Xen
16 matches
Mail list logo
