On Wed, Feb 17, 2016 at 05:39:23PM -0500, Boris Ostrovsky wrote:
> Hmm. I think you are right --- I was following wrong branch of the 'if'
> statement. We are always going straight to note_page().
Yap. The is_hypervisor_range() - without the "!" - does note_page().
> Then yes, we should be able t
On 02/17/2016 05:18 PM, Andy Lutomirski wrote:
On Wed, Feb 17, 2016 at 2:03 PM, Borislav Petkov wrote:
On Wed, Feb 17, 2016 at 04:21:56PM -0500, Boris Ostrovsky wrote:
That's exactly the point: if something is mapped it's an error for a
non-PV kernel.
How would something be mapped there? __PA
On Wed, Feb 17, 2016 at 11:03:04PM +0100, Borislav Petkov wrote:
> On Wed, Feb 17, 2016 at 04:21:56PM -0500, Boris Ostrovsky wrote:
> > That's exactly the point: if something is mapped it's an error for a
> > non-PV kernel.
>
> How would something be mapped there? __PAGE_OFFSET is
> 0x8800
On 02/17/2016 05:03 PM, Borislav Petkov wrote:
On Wed, Feb 17, 2016 at 04:21:56PM -0500, Boris Ostrovsky wrote:
That's exactly the point: if something is mapped it's an error for a
non-PV kernel.
How would something be mapped there? __PAGE_OFFSET is
0x8800.
Or are you thinking abou
On Wed, Feb 17, 2016 at 2:03 PM, Borislav Petkov wrote:
> On Wed, Feb 17, 2016 at 04:21:56PM -0500, Boris Ostrovsky wrote:
>> That's exactly the point: if something is mapped it's an error for a
>> non-PV kernel.
>
> How would something be mapped there? __PAGE_OFFSET is
> 0x8800.
>
> O
On Wed, Feb 17, 2016 at 04:21:56PM -0500, Boris Ostrovsky wrote:
> That's exactly the point: if something is mapped it's an error for a
> non-PV kernel.
How would something be mapped there? __PAGE_OFFSET is
0x8800.
Or are you thinking about some insanely b0rked kernel code mapping stu
On 02/17/2016 03:49 PM, Borislav Petkov wrote:
On Wed, Feb 17, 2016 at 12:07:13PM -0800, Luis R. Rodriguez wrote:
OK so here's a wiki to keep track of progress of the difference uses:
http://kernelnewbies.org/KernelProjects/remove-paravirt-enabled
It seems we have a resolution one way or anoth
On Wed, Feb 17, 2016 at 12:49 PM, Borislav Petkov wrote:
> On Wed, Feb 17, 2016 at 12:07:13PM -0800, Luis R. Rodriguez wrote:
>> OK so here's a wiki to keep track of progress of the difference uses:
>>
>> http://kernelnewbies.org/KernelProjects/remove-paravirt-enabled
>>
>> It seems we have a reso
On Wed, Feb 17, 2016 at 12:07:13PM -0800, Luis R. Rodriguez wrote:
> OK so here's a wiki to keep track of progress of the difference uses:
>
> http://kernelnewbies.org/KernelProjects/remove-paravirt-enabled
>
> It seems we have a resolution one way or another for all except for
> the use on arch/
OK so here's a wiki to keep track of progress of the difference uses:
http://kernelnewbies.org/KernelProjects/remove-paravirt-enabled
It seems we have a resolution one way or another for all except for
the use on arch/x86/mm/dump_pagetables.c, is that right? So to be
clear we should not merge mor
On Mon, Feb 08, 2016 at 10:31:36AM -0500, Boris Ostrovsky wrote:
>
>
> On 02/06/2016 03:05 PM, Andy Lutomirski wrote:
> >
> >Anyway, this is all ridiculous. I propose that rather than trying to
> >clean up paravirt_enabled, you just delete it. Here are its users:
> >
> >static inline bool is_hy
On Mon, Feb 08, 2016 at 04:46:08PM +0100, Borislav Petkov wrote:
> On Mon, Feb 08, 2016 at 10:31:36AM -0500, Boris Ostrovsky wrote:
> > This range is reserved for hypervisors but the only hypervisor that uses it
> > is Xen PV (lguest doesn't run in 64-bit mode).
>
> Yeah, this is mentioned in arch
On Sat, Feb 06, 2016 at 12:05:32PM -0800, Andy Lutomirski wrote:
> On Sat, Feb 6, 2016 at 12:59 AM, Luis R. Rodriguez wrote:
> > On Fri, Feb 05, 2016 at 11:11:34PM -0800, Andy Lutomirski wrote:
> >> On Feb 5, 2016 8:30 PM, "Luis R. Rodriguez" wrote:
> >> >
> >> > paravirt_enabled conveys the idea
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 02/06/2016 03:59 AM, Luis R. Rodriguez wrote:
The enumeration of legacy crap by ACPI boot flags seems to provide enough
details to suit our needs if we really wanted to zero down on the specifics of
what paravirt_legacy() means, there are these flags:
/* Masks for FADT IA-PC Boot Architectu
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 Mon, Feb 8, 2016 at 7:31 AM, Boris Ostrovsky
wrote:
>
>
> On 02/06/2016 03:05 PM, Andy Lutomirski wrote:
>>
>>
>> Anyway, this is all ridiculous. I propose that rather than trying to
>> clean up paravirt_enabled, you just delete it. Here are its users:
>>
>> static inline bool is_hypervisor_r
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 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: we've had this before. The hypervisor
> >should
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
On Mon, Feb 08, 2016 at 10:31:36AM -0500, Boris Ostrovsky wrote:
> This range is reserved for hypervisors but the only hypervisor that uses it
> is Xen PV (lguest doesn't run in 64-bit mode).
Yeah, this is mentioned in arch/x86/include/asm/page_64_types.h:
/*
* Set __PAGE_OFFSET to the most nega
On 02/06/2016 05:04 PM, Borislav Petkov wrote:
On Sat, Feb 06, 2016 at 12:05:32PM -0800, Andy Lutomirski wrote:
int __init microcode_init(void)
{
[...]
if (paravirt_enabled() || dis_ucode_ldr)
return -EINVAL;
This is also asking "are we the natively booted k
On 02/06/2016 03:05 PM, Andy Lutomirski wrote:
Anyway, this is all ridiculous. I propose that rather than trying to
clean up paravirt_enabled, you just delete it. Here are its users:
static inline bool is_hypervisor_range(int idx)
{
/*
* 8000 - 87ff is res
On Sat, Feb 06, 2016 at 12:05:32PM -0800, Andy Lutomirski wrote:
> int __init microcode_init(void)
> {
> [...]
> if (paravirt_enabled() || dis_ucode_ldr)
> return -EINVAL;
>
> This is also asking "are we the natively booted kernel?" This is
> plausibly useful for r
On Sat, Feb 6, 2016 at 12:59 AM, Luis R. Rodriguez wrote:
> On Fri, Feb 05, 2016 at 11:11:34PM -0800, Andy Lutomirski wrote:
>> On Feb 5, 2016 8:30 PM, "Luis R. Rodriguez" wrote:
>> >
>> > paravirt_enabled conveys the idea that if this is set or if
>> > paravirt_enabled() returns true you are in
On Fri, Feb 05, 2016 at 11:11:34PM -0800, Andy Lutomirski wrote:
> On Feb 5, 2016 8:30 PM, "Luis R. Rodriguez" wrote:
> >
> > paravirt_enabled conveys the idea that if this is set or if
> > paravirt_enabled() returns true you are in a paravirtualized
> > environment. This is not true by any means,
On Feb 5, 2016 8:30 PM, "Luis R. Rodriguez" wrote:
>
> paravirt_enabled conveys the idea that if this is set or if
> paravirt_enabled() returns true you are in a paravirtualized
> environment. This is not true by any means, and left as-is
> is just causing confusion and is prone to be misused and
paravirt_enabled conveys the idea that if this is set or if
paravirt_enabled() returns true you are in a paravirtualized
environment. This is not true by any means, and left as-is
is just causing confusion and is prone to be misused and abused.
This primitive is really only useful to determine if
40 matches
Mail list logo
