- b...@suse.de wrote:
> On Thu, Nov 27, 2014 at 09:14:11AM -0800, Boris Ostrovsky wrote:
> > The overnight tests passed. This includes baremetal, HVM and PV(H),
> > 32- and 64-bit.
>
> Cool. Want to send a proper patch for 3.18 and CC: stable?
>
So I am not convinced that we actually updat
On Thu, Nov 27, 2014 at 09:14:11AM -0800, Boris Ostrovsky wrote:
> The overnight tests passed. This includes baremetal, HVM and PV(H),
> 32- and 64-bit.
Cool. Want to send a proper patch for 3.18 and CC: stable?
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatti
- b...@suse.de wrote:
> On Thu, Nov 27, 2014 at 11:21:19AM -0500, Konrad Rzeszutek Wilk
> wrote:
> > > Ok, but let's have a clean design: maybe have a weak default stub
> which
> > > returns false when PARAVIRT is not enabled in the .config and then
> add
> > > an override in, say, arch/x86/k
On Thu, Nov 27, 2014 at 11:21:19AM -0500, Konrad Rzeszutek Wilk wrote:
> > Ok, but let's have a clean design: maybe have a weak default stub which
> > returns false when PARAVIRT is not enabled in the .config and then add
> > an override in, say, arch/x86/kernel/paravirt.c which returns true when
>
On Thu, Nov 27, 2014 at 10:12:28AM +0100, Borislav Petkov wrote:
> On Wed, Nov 26, 2014 at 07:13:02PM -0800, Boris Ostrovsky wrote:
> > I was confusing you: accessing dis_ucode_ldr by virtual address does
> > work on PV. But we then fail later, in load_ucode_intel_ap(), because
> > it also tries to
On Wed, Nov 26, 2014 at 07:13:02PM -0800, Boris Ostrovsky wrote:
> I was confusing you: accessing dis_ucode_ldr by virtual address does
> work on PV. But we then fail later, in load_ucode_intel_ap(), because
> it also tries to use __pa_nodebug() which can't be used by PV.
>
> So if accessing dis_uc
- b...@suse.de wrote:
> On Wed, Nov 26, 2014 at 07:39:26AM -0500, boris ostrovsky wrote:
> > https://lkml.org/lkml/2014/11/25/973 is all I have right now.
>
> Ok, so the Code: section from this splat says:
>
> 25: 55 push %ebp
> 26: 89 e5 mov
On Wed, Nov 26, 2014 at 07:39:26AM -0500, boris ostrovsky wrote:
> https://lkml.org/lkml/2014/11/25/973 is all I have right now.
Ok, so the Code: section from this splat says:
25: 55 push %ebp
26: 89 e5 mov%esp,%ebp
28: 83 ec 08
On 11/26/2014 5:55 AM, Borislav Petkov wrote:
On Wed, Nov 26, 2014 at 12:00:45AM -0500, Boris Ostrovsky wrote:
Sigh... I take this back. It breaks 32-bit baremetal. I haven't looked any
further but it seems to be dying very early. I suspect cpuid pv_op is not
set up yet. If that's true, perhaps
On Wed, Nov 26, 2014 at 12:00:45AM -0500, Boris Ostrovsky wrote:
> Sigh... I take this back. It breaks 32-bit baremetal. I haven't looked any
> further but it seems to be dying very early. I suspect cpuid pv_op is not
> set up yet. If that's true, perhaps you could check whether it is valid in
> x8
On 11/25/2014 05:18 PM, Borislav Petkov wrote:
Adding x86 people.
On Tue, Nov 25, 2014 at 04:59:34PM -0500, Boris Ostrovsky wrote:
This should be cpuid(0x1, &eax, &ebx, &ecx, &edx). Otherwise we are not
getting bits that the hypervisor wants the guest to see (on Xen cpuid()
turns into hypercall
Adding x86 people.
On Tue, Nov 25, 2014 at 04:59:34PM -0500, Boris Ostrovsky wrote:
> This should be cpuid(0x1, &eax, &ebx, &ecx, &edx). Otherwise we are not
> getting bits that the hypervisor wants the guest to see (on Xen cpuid()
> turns into hypercall, on baremetal it's native).
>
> With that
On 11/25/2014 04:17 PM, Borislav Petkov wrote:
On Tue, Nov 25, 2014 at 03:36:34PM -0500, Konrad Rzeszutek Wilk wrote:
Is there an use-case for this in virtualization at all?
Not that I know of...
Why not make it in general then? Like:
if (cpu_has_hypervisor)
return;
Ah, good idea. A
On Tue, Nov 25, 2014 at 03:36:34PM -0500, Konrad Rzeszutek Wilk wrote:
> Is there an use-case for this in virtualization at all?
Not that I know of...
> Why not make it in general then? Like:
>
> if (cpu_has_hypervisor)
> return;
Ah, good idea. Although we need to do it by-foot because th
On Tue, Nov 25, 2014 at 09:26:28PM +0100, Borislav Petkov wrote:
> On Tue, Nov 25, 2014 at 02:28:46PM -0500, Boris Ostrovsky wrote:
> > You'd have to decide at runtime --- many baremetal systems are
> > compiled with PARAVIRT.
>
> Right, but the microcode loader is not used at all on PV, right?
I
On Tue, Nov 25, 2014 at 02:28:46PM -0500, Boris Ostrovsky wrote:
> You'd have to decide at runtime --- many baremetal systems are
> compiled with PARAVIRT.
Right, but the microcode loader is not used at all on PV, right?
If so, I'd like to add a arch_something_blabla_disabled_loader()
function wh
On 11/25/2014 02:08 PM, Borislav Petkov wrote:
On Tue, Nov 25, 2014 at 01:55:29PM -0500, Boris Ostrovsky wrote:
On 11/25/2014 01:43 PM, Borislav Petkov wrote:
On Tue, Nov 25, 2014 at 01:43:26PM -0500, Boris Ostrovsky wrote:
I don't think this routine is called on PV.
They're either both calle
On 11/25/2014 02:03 PM, Borislav Petkov wrote:
On Tue, Nov 25, 2014 at 01:55:29PM -0500, Boris Ostrovsky wrote:
On 11/25/2014 01:43 PM, Borislav Petkov wrote:
On Tue, Nov 25, 2014 at 01:43:26PM -0500, Boris Ostrovsky wrote:
I don't think this routine is called on PV.
They're either both calle
On Tue, Nov 25, 2014 at 01:55:29PM -0500, Boris Ostrovsky wrote:
> On 11/25/2014 01:43 PM, Borislav Petkov wrote:
> >On Tue, Nov 25, 2014 at 01:43:26PM -0500, Boris Ostrovsky wrote:
> >>I don't think this routine is called on PV.
> >They're either both called or none is. At least on baremetal, that
On Tue, Nov 25, 2014 at 01:55:29PM -0500, Boris Ostrovsky wrote:
> On 11/25/2014 01:43 PM, Borislav Petkov wrote:
> >On Tue, Nov 25, 2014 at 01:43:26PM -0500, Boris Ostrovsky wrote:
> >>I don't think this routine is called on PV.
> >They're either both called or none is. At least on baremetal, that
On 11/25/2014 01:43 PM, Borislav Petkov wrote:
On Tue, Nov 25, 2014 at 01:43:26PM -0500, Boris Ostrovsky wrote:
I don't think this routine is called on PV.
They're either both called or none is. At least on baremetal, that is.
PV guests don't start with startup_32.
We are coming from a resu
On Tue, Nov 25, 2014 at 10:45:01AM -0800, Greg Kroah-Hartman wrote:
> Does that mean it is also broken in Linus's tree?
Should be.
> If so, please fix it there.
Gladly, if Boris would share some more info as to why it breaks the PV
gunk...
--
Regards/Gruss,
Boris.
Sent from a fat crate un
On 11/25/2014 01:45 PM, Greg Kroah-Hartman wrote:
On Tue, Nov 25, 2014 at 01:12:10PM -0500, Boris Ostrovsky wrote:
On 11/19/2014 03:52 PM, Greg Kroah-Hartman wrote:
3.17-stable review patch. If anyone has any objections, please let me know.
This breaks PV on Xen.
Does that mean it is also b
On Tue, Nov 25, 2014 at 01:12:10PM -0500, Boris Ostrovsky wrote:
> On 11/19/2014 03:52 PM, Greg Kroah-Hartman wrote:
> >3.17-stable review patch. If anyone has any objections, please let me know.
>
>
> This breaks PV on Xen.
Does that mean it is also broken in Linus's tree? If so, please fix i
On Tue, Nov 25, 2014 at 01:43:26PM -0500, Boris Ostrovsky wrote:
> I don't think this routine is called on PV.
They're either both called or none is. At least on baremetal, that is.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from t
On 11/25/2014 01:24 PM, Borislav Petkov wrote:
On Tue, Nov 25, 2014 at 01:12:10PM -0500, Boris Ostrovsky wrote:
On 11/19/2014 03:52 PM, Greg Kroah-Hartman wrote:
3.17-stable review patch. If anyone has any objections, please let me know.
This breaks PV on Xen.
-boris
--
F
On Tue, Nov 25, 2014 at 01:12:10PM -0500, Boris Ostrovsky wrote:
> On 11/19/2014 03:52 PM, Greg Kroah-Hartman wrote:
> >3.17-stable review patch. If anyone has any objections, please let me know.
>
>
> This breaks PV on Xen.
>
> -boris
>
> >
> >--
> >
> >From: Borislav Petkov
On 11/19/2014 03:52 PM, Greg Kroah-Hartman wrote:
3.17-stable review patch. If anyone has any objections, please let me know.
This breaks PV on Xen.
-boris
--
From: Borislav Petkov
commit 85be07c32496dc264661308e4d9d4e9ccaff8072 upstream.
We should be accessing it thro
3.17-stable review patch. If anyone has any objections, please let me know.
--
From: Borislav Petkov
commit 85be07c32496dc264661308e4d9d4e9ccaff8072 upstream.
We should be accessing it through a pointer, like on the BSP.
Tested-by: Richard Hendershot
Fixes: 65cef1311d5d ("x8
29 matches
Mail list logo
