[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <512937A8.9050906@zytor.com>
Date: Sat, 23 Feb 2013 13:42:00 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Yinghai Lu <yinghai@...nel.org>
CC: Konrad Rzeszutek Wilk <konrad@...nel.org>,
Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
"H. Peter Anvin" <hpa@...ux.intel.com>,
Stefano Stabellini <stefano.stabellini@...citrix.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] x86/mm changes for v3.9-rc1
On 02/23/2013 01:37 PM, Yinghai Lu wrote:
> On Sat, Feb 23, 2013 at 11:43 AM, Konrad Rzeszutek Wilk
> <konrad@...nel.org> wrote:
>>>>> Also you should check condition about calling xen_get_user_pgd().
>>>>
>>>> Could you elaborate please?
>>>
>>> only call xen_get_user_pgd() when it should be called.
>>
>> I should have been more explicit. When I was saying "elaborate" I was
>> soliciting for advice on the 'check condition' and how to make it robust.
>
> your 64bit xen_write_cr3_init, is just xen_write_cr3 without
> xen_get_user_pgd calling.
> plus set xen_write_cr3 to ops.write_cr3.
>
> so if you could have way to find out when xen_get_user_pgd could be used,
> new xen_write_cr3_init need to check that, then set ops.write_cr3 and
> call ops.write_cr3
> otherwise will still call slim version without update ops.write_cr3
> and bail out early.
>
Yes, and that's the right thing to do, *or* you can make the init
version ask "do we have userspace yet" and if so switch the pointer and
chain the other function. The latter will save you from having to do a
test every time.
However, the assumption that we will only set cr3 once before userspace
is still too fragile. It makes sense for a quick fix because 32 bits
already had the same assumption, but this needs to be cleaned up in the
future.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists