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
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 use
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
- 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,
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.
- 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 update
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
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,
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
- 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 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 b...@suse.de
commit 85be07c32496dc264661308e4d9d4e9ccaff8072 upstream.
We should be
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 b...@suse.de
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
--
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
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 it
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
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
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
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 is.
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 is.
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
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
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
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?
Is
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 the
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.
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 change
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,
3.17-stable review patch. If anyone has any objections, please let me know.
--
From: Borislav Petkov b...@suse.de
commit 85be07c32496dc264661308e4d9d4e9ccaff8072 upstream.
We should be accessing it through a pointer, like on the BSP.
Tested-by: Richard Hendershot
29 matches
Mail list logo
