On 10/04/17 08:58, Josh Poimboeuf wrote:
> Add alternative patching support for replacing an instruction with an
> indirect call. This will be needed for the paravirt alternatives.
I have a patchset that generalizes the alternatives in what I think is a
more robust way. I really, really want to
On 09/22/17 11:57, Kees Cook wrote:
> On Fri, Sep 22, 2017 at 11:38 AM, H. Peter Anvin wrote:
>> We lose EBX on 32 bits, but we don't lose RBX on 64 bits - since x86-64
>> has RIP-relative addressing there is no need for a dedicated PIC register.
>
> FWIW, since gcc
On 09/22/17 09:32, Ingo Molnar wrote:
>
> BTW., I think things improved with ORC because with ORC we have RBP as an
> extra
> register and with PIE we lose RBX - so register pressure in code generation
> is
> lower.
>
We lose EBX on 32 bits, but we don't lose RBX on 64 bits - since x86-64
ha
On 08/21/17 07:28, Peter Zijlstra wrote:
>
> Ah, I see, this is large mode and that needs to use MOVABS to load 64bit
> immediates. Still, small RIP relative should be able to live at any
> point as long as everything lives inside the same 2G relative range, so
> would still allow the goal of incr
On 08/21/17 07:31, Peter Zijlstra wrote:
> On Tue, Aug 15, 2017 at 07:20:38AM -0700, Thomas Garnier wrote:
>> On Tue, Aug 15, 2017 at 12:56 AM, Ingo Molnar wrote:
>
>>> Have you considered a kernel with -mcmodel=small (or medium) instead of
>>> -fpie
>>> -mcmodel=large? We can pick a random 2GB
..@zytor.com>
On July 19, 2017 3:58:07 PM PDT, Ard Biesheuvel
wrote:
>On 19 July 2017 at 23:27, H. Peter Anvin wrote:
>> On 07/19/17 08:40, Thomas Garnier wrote:
>>>>
>>>> This doesn't look right. It's accessing a per-cpu variable. The
>>>
gt;
On July 19, 2017 4:25:56 PM PDT, Thomas Garnier wrote:
>On Wed, Jul 19, 2017 at 4:08 PM, H. Peter Anvin wrote:
>> On 07/19/17 15:47, Thomas Garnier wrote:
>>> On Wed, Jul 19, 2017 at 3:33 PM, H. Peter Anvin
>wrote:
>>>> On 07/18/17 15:33, Thomas Garnier wrot
On 07/19/17 19:21, H. Peter Anvin wrote:
> On 07/19/17 16:33, H. Peter Anvin wrote:
>>>
>>> I agree that it is odd but that's how the compiler generates code. I
>>> will re-explore PIC options with mcmodel=small or medium, as mentioned
>>> on othe
On 07/19/17 16:33, H. Peter Anvin wrote:
>>
>> I agree that it is odd but that's how the compiler generates code. I
>> will re-explore PIC options with mcmodel=small or medium, as mentioned
>> on other threads.
>
> Why should the way compiler generates co
On 07/19/17 11:26, Thomas Garnier wrote:
> On Tue, Jul 18, 2017 at 8:08 PM, Brian Gerst wrote:
>> On Tue, Jul 18, 2017 at 6:33 PM, Thomas Garnier wrote:
>>> Perpcu uses a clever design where the .percu ELF section has a virtual
>>> address of zero and the relocation code avoid relocating specific
On 07/19/17 15:47, Thomas Garnier wrote:
> On Wed, Jul 19, 2017 at 3:33 PM, H. Peter Anvin wrote:
>> On 07/18/17 15:33, Thomas Garnier wrote:
>>> The x86 relocation tool generates a list of 32-bit signed integers. There
>>> was no need to use 64-bit integers because al
On 07/18/17 15:33, Thomas Garnier wrote:
> Change the assembly code to use only relative references of symbols for the
> kernel to be PIE compatible.
>
> Position Independent Executable (PIE) support will allow to extended the
> KASLR randomization range below the -2G memory limit.
>
> Signed-off
On 07/18/17 15:33, Thomas Garnier wrote:
> The x86 relocation tool generates a list of 32-bit signed integers. There
> was no need to use 64-bit integers because all addresses where above the 2G
> top of the memory.
>
> This change add a large-reloc option to generate 64-bit unsigned integers.
> I
On 07/19/17 08:40, Thomas Garnier wrote:
>>
>> This doesn't look right. It's accessing a per-cpu variable. The
>> per-cpu section is an absolute, zero-based section and not subject to
>> relocation.
>
> PIE does not respect the zero-based section, it tries to have
> everything relative. Patch 16
On 07/18/17 15:33, Thomas Garnier wrote:
> With PIE support and KASLR extended range, the modules may be further
> away from the kernel than before breaking mcmodel=kernel expectations.
>
> Add an option to build modules with mcmodel=large. The modules generated
> code will make no assumptions on
,"Luis R . Rodriguez" ,Stanislaw Gruszka
,Peter Zijlstra ,Josh Poimboeuf
,Vitaly Kuznetsov ,Tim Chen
,Joerg Roedel
,=?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= ,the
arch/x86 maintainers ,LKML
,linux-...@vger.kernel.org,kasan-dev
,Linux-MM ,Linux PM list
,linux-...@vger.kernel.org,xen-de...@lists.xenpr
On 12/06/16 00:46, Jan Beulich wrote:
>> +
>> +#ifdef CONFIG_X86_32
>> +asm volatile (
>> +"pushfl\n\t"
>> +"pushl %%cs\n\t"
>> +"pushl $1f\n\t"
>> +"iret\n\t"
>> +"1:"
>> +: "+r" (__sp) : : "cc", "memory");
>
> I don't th
On September 14, 2016 6:17:51 PM PDT, Andy Lutomirski
wrote:
>On Wed, Sep 14, 2016 at 3:03 PM, Kyle Huey wrote:
>> On Wed, Sep 14, 2016 at 2:35 PM, Dave Hansen
>> wrote:
>>> On 09/14/2016 02:01 PM, Kyle Huey wrote:
>
>>> Is any of this useful to optimize away at compile-time? We have
>config
>
Vrabel ,Konrad Rzeszutek Wilk
,Michael Brown ,Juergen Gross
,Andrew Cooper ,Andy Shevchenko
,Paul Gortmaker
,"xen-de...@lists.xensource.com"
,Andi Kleen
,pali.ro...@gmail.com,dvh...@infradead.org,platform-driver-...@vger.kernel.org,Michal
Marek ,Rasmus Villemoes ,Jiri
Kosina ,=?UTF-8?B?7KGw
mcg...@kernel.org,a...@redhat.com,t...@linutronix.de,mi...@redhat.com,jpoim...@redhat.com,b...@alien8.de,li...@arm.linux.org.uk,mhira...@kernel.org,masami.hiramatsu...@hitachi.com,jba...@akamai.com,heiko.carst...@de.ibm.com,ana...@linux.vnet.ibm.com,anil.s.keshavamur...@intel.com,da...@davemloft.ne
t...@linutronix.de,mi...@redhat.com,b...@alien8.de,li...@arm.linux.org.uk,masami.hiramatsu...@hitachi.com,jba...@akamai.com,heiko.carst...@de.ibm.com,ana...@linux.vnet.ibm.com,anil.s.keshavamur...@intel.com,da...@davemloft.net,real...@gmail.com,x...@kernel.org,l...@amacapital.net,keesc...@chromium.
On 04/22/2016 02:47 AM, tip-bot for Jan Beulich wrote:
> Commit-ID: 103f6112f253017d7062cd74d17f4a514ed4485c
> Gitweb: http://git.kernel.org/tip/103f6112f253017d7062cd74d17f4a514ed4485c
> Author: Jan Beulich
> AuthorDate: Thu, 21 Apr 2016 00:27:04 -0600
> Committer: Ingo Molnar
> Commit
On 04/04/16 11:24, Luis R. Rodriguez wrote:
> On Mon, Apr 04, 2016 at 09:01:06AM -0700, H. Peter Anvin wrote:
>> On 03/31/16 13:03, Luis R. Rodriguez wrote:
>>> Andy S, Peter, Thomas, Jiang (or who might know),
>>>
>>> Do Intel MID platforms exist with PNP BIOS
On 03/31/16 13:03, Luis R. Rodriguez wrote:
> Andy S, Peter, Thomas, Jiang (or who might know),
>
> Do Intel MID platforms exist with PNP BIOS support? What abot CE4100?
> As it stands I don't see anything that would prevent this but I would
> suspect a possibility might be that it doesn't. I'm sa
On 02/23/2016 03:36 PM, Luis R. Rodriguez wrote:
>
>> 4. the only useful operator on a range is "is address X inside this
>>range"; this operator is likely *not* useful for a table, since
>>if you have to ever invoke it you are probably doing something very
>>wrong.
>
> kprobe uses it
On 02/23/2016 03:08 PM, Luis R. Rodriguez wrote:
>
> OK yes I see the issue now. I've modified this to use const, and
> retested the kprobe patch and it works well still. kprobe would not
> use LINKTABLE_TEXT, instead it uses its own macro, however users of
> LINKTABLE_TEXT would then have const d
On 02/19/16 13:06, Luis R. Rodriguez wrote:
>>
>> I think the \n\t is unnecessary.
>
> Super! I wonder if we we can just use this on s390 as well without it pooping?
> I ask as this would set a precedent.
>
Ask Heike, but I think just ; or \n ought be be fine. I do not know of
*any* case where
On 02/19/2016 05:45 AM, Luis R. Rodriguez wrote:
> +/**
> + * LINKTABLE_RUN_ERR - run each linker table entry func and return error if
> any
> + *
> + * @tbl: linker table
> + * @func: structure name for the function name we want to call.
> + * @args...: arguments to pass to func
> + *
> + * Examp
On 02/19/2016 05:45 AM, Luis R. Rodriguez wrote:
> +
> +/**
> + * DOC: Regular linker linker table constructors
> + *
> + * Regular constructors are expected to be used for valid linker table
> entries.
> + * Valid uses of weak entries other than the beginning and is currently
> + * untested but s
On 02/19/2016 05:45 AM, Luis R. Rodriguez wrote:
> With a generic linker tables solution in place we
> need a general asm solution for declaring entries
> with asm. The first easy target is to cover the C
> asm declarations, guard the header file for now
> and define a first generic entry push_sect
On 02/19/2016 05:45 AM, Luis R. Rodriguez wrote:
> This is my v2 of the original linker table work [0], now with
> six proof of concepts ports of existing code using custom section
> with custom linker script modifications:
>
> * DEFINE_LINKTABLE_TEXT(char, kprobes);
> * DEFINE_LINKTABLE_DATA(
On 02/02/2016 04:22 PM, Luis R. Rodriguez wrote:
>>
>> Should it be possible to resuse free_init_pages() and/or
>> free_reserved_area() only for routines (members in the array in this
>> case of a struct of fns) that don't meet our subarch once we're done
>> iterating over the routies and know we c
On 01/22/2016 05:44 AM, Michael Matz wrote:
> Hi,
>
> On Thu, 21 Jan 2016, H. Peter Anvin wrote:
>
>> Something that confuses me is that gcc seems to give these sections the
>> "aw" attributes which makes as complain. This might be a gcc bug.
>
> Workar
On 01/25/16 13:12, Luis R. Rodriguez wrote:
>>
>> Perhaps, but someone would still have to set hardware_subarch. And
>> it's hvmlite_bootparams() that does it.
>
> No, Xen would do it as well, essentially all of hvmlite_bootparams() could be
> done in Xen.
>
Or a stub code.
-hpa
On January 23, 2016 8:12:23 AM PST, Konrad Rzeszutek Wilk
wrote:
>On January 23, 2016 11:01:06 AM EST, "H. Peter Anvin"
>wrote:
>>On January 23, 2016 7:34:33 AM PST, Konrad Rzeszutek Wilk
>> wrote:
>>>
>>>>However, this stub belongs in Linux,
On January 23, 2016 7:34:33 AM PST, Konrad Rzeszutek Wilk
wrote:
>
>>However, this stub belongs in Linux, not in the Xen toolstack. That
>>way, when the Linux boot protocol is modified, both sides can be
>>updated
>>accordingly.
>
>I would add that this idea is borrowed from the EFI stub code th
On 01/22/2016 05:44 AM, Michael Matz wrote:
> Hi,
>
> On Thu, 21 Jan 2016, H. Peter Anvin wrote:
>
>> Something that confuses me is that gcc seems to give these sections the
>> "aw" attributes which makes as complain. This might be a gcc bug.
>
> Workar
On 01/21/16 16:25, Luis R. Rodriguez wrote:
>>
>> Basically, if the hardware is enumerable using standard PC mechanisms (PCI,
>> ACPI) and doesn't need a special boot flow it should use type 0.
>
> I can extend the documentation as part of this to be clear.
>
> I will note though that this still
On 01/21/16 14:25, Luis R. Rodriguez wrote:
> On Thu, Jan 21, 2016 at 1:37 PM, Konrad Rzeszutek Wilk
> wrote:
>>> Sure, do we know if that ICC compatible? Do we care? There are a
>>> series of ICC hacks put in place on ipxe's original solution which
>>> I've folded in, it seems that works but if w
On 01/21/16 12:05, Luis R. Rodriguez wrote:
>
>> At least on i386,
>> we have to do this in assembly code.
>
> Neat! How is that order kept?
>
Right now subarch_entries[] is just an array indexed by subarch number
hardcoded in head_32.S.
However, if you have a list of (id, target) then you cou
On 12/17/15 20:40, H. Peter Anvin wrote:
>>
>> const struct
>> foo__attribute__((used,section(".rodata.tbl.tablename.0"))) tablename[0];
>>
>> const struct
>> foo__attribute__((used,section(".rodata.tbl.tablename.999")))
>> tablena
On 01/21/16 11:50, H. Peter Anvin wrote:
>
> Right... we already do that.
>
> I don't even think you need to initialize any tables. At least on i386,
> we have to do this in assembly code. However, it is just a simple table
> walk. :)
>
It might make more sense to
On 01/21/16 11:46, Luis R. Rodriguez wrote:
> On Thu, Jan 21, 2016 at 11:25 AM, H. Peter Anvin wrote:
>>> And that's exactly what HVMlite does. Most of this shim layer is setting
>>> up boot_params, after which we jump to standard x86 boot path (i.e.
>>> star
On 01/21/16 05:45, Boris Ostrovsky wrote:
>> I don't think the hypervisor should be setting Linux specific boot
>> related parameters, the boot ABI should be OS agnostic. IMHO, a small
>> shim should be added to Linux in order to set what Linux requires when
>> entering from a Xen entry point.
For
On January 20, 2016 3:15:48 PM PST, Michael Brown wrote:
>>> + * To solve this problem linker tables can be used on Linux, it
>enables you to
>>> + * always force compiling of select features that one wishes to
>avoid bit-rot
>>> + * while still enabling you to disable linking feature code into
>t
On January 20, 2016 2:12:49 PM PST, "Luis R. Rodriguez"
wrote:
>On Wed, Jan 20, 2016 at 1:41 PM, H. Peter Anvin wrote:
>> On 01/20/16 13:33, Luis R. Rodriguez wrote:
>>>
>>> That's correct for PV and PVH, likewise when qemu is required for
>HVM
>&
On 01/20/16 13:33, Luis R. Rodriguez wrote:
>
> That's correct for PV and PVH, likewise when qemu is required for HVM
> qemu could set it. I have the qemu change done but that should only
> cover HVM. A common place to set this as well could be the hypervisor,
> but currently the hypervisor doesn'
On January 15, 2016 4:43:04 PM PST, "Luis R. Rodriguez" wrote:
>On Fri, Jan 15, 2016 at 03:47:25PM -0800, Andy Lutomirski wrote:
>> On Fri, Jan 15, 2016 at 2:08 PM, Luis R. Rodriguez
>wrote:
>> > I will be respinning the generic Linux linker table solution [0]
>soon
>> > based on hpa's feedback a
On December 18, 2015 10:50:40 AM PST, "Luis R. Rodriguez"
wrote:
>On Thu, Dec 17, 2015 at 08:25:19PM -0800, H. Peter Anvin wrote:
>> On 12/17/15 15:46, Luis R. Rodriguez wrote:
>> >
>> > I explain why I do that there but the gist of it is that on Linux
>
On 12/17/15 20:25, H. Peter Anvin wrote:
>
> /* DECLARE_LINKTABLE_RO */
> extern const struct foo tablename[], tablename__end[];
>
> /* DEFINE_LINKTABLE_RO */
> DECLARE_LINKTABLE_RO(struct foo, tablename);
>
> const struct
> foo__attribute__((used,section(".roda
On 12/17/15 15:46, Luis R. Rodriguez wrote:
>
> I explain why I do that there but the gist of it is that on Linux we may also
> want stronger semantics for specific linker table solutions, and solutions
> such
> as those devised on the IOMMU init stuff do memmove() for sorting depending on
> sema
On 12/17/15 12:48, Andy Lutomirski wrote:
>
> I'm entirely ignorant of anything going on in gPXE/iPXE.
>
> Can you explain what a linker table *does*? It looks like all you've
> done in this patch is to move code around. What actually happens?
>
A linker table is a data structure that is stit
I think we can make this even more generic. In particular, I would love
to see a solution for link tables that:
a) can be used for any kind of data structures, not just function
pointers (the latter is a specialization of the former);
b) doesn't need any changes to the linker scripts once the ini
On December 15, 2015 2:16:29 PM PST, "Luis R. Rodriguez"
wrote:
>From: "Luis R. Rodriguez"
>
> A long time ago in a galaxy far,
> far away...
>
>Konrad Rzeszutek Wilk posted patches which eventually got merged to
>help
>with modularizing the IOMMUs we have on x86 [0]. Thi
On 11/16/15 12:22, Borislav Petkov wrote:
>
> Huh, so what's wrong with a jump:
>
> jmp 1f
> swapgs
> 1:
>
What is the point of that jump?
>> If it would make you feel better, it could be X86_BUG_XENPV :-p
>
> That doesn't matter - I just don't want to open the flood gates o
On 11/05/15 10:56, Boris Ostrovsky wrote:
> The range between 0x8000 and 0x87ff is reserved
> for hypervisor and therefore we should not try to follow PGD's indexes
> corresponding to those addresses.
>
> While this has alsways been a problem, with commit e1a58320a38d ("x86
On 09/21/2015 09:36 AM, Linus Torvalds wrote:
>
> How many msr reads are so critical that the function call
> overhead would matter? Get rid of the inline version of the _safe()
> thing too, and put that thing there too.
>
Probably only the ones that may go in the context switch path.
-
However, the difference between one CONFIG and another is quite frankly crazy.
We should explicitly use the safe versions where this is appropriate, and then
yes, we should do this.
Yet another reason the paravirt code is batshit crazy.
On September 17, 2015 2:31:34 AM PDT, Borislav Petkov wr
On 07/27/2015 10:29 PM, Andy Lutomirski wrote:
> modify_ldt has questionable locking and does not synchronize
> threads. Improve it: redesign the locking and synchronize all
> threads' LDTs using an IPI on all modifications.
>
> This will dramatically slow down modify_ldt in multithreaded
> progr
One option might be to do the addition in assembly, i.e.:
"i" (key), "i" (index)
... and put the addition into the assembly source.
On August 12, 2015 11:17:17 AM PDT, Boris Ostrovsky
wrote:
>On 08/12/2015 01:46 PM, Peter Zijlstra wrote:
>> On Wed, Aug 12, 2015 at 07:21:05PM +0200, Peter Zijls
On 07/28/2015 08:02 AM, Julien Grall wrote:
> Hi all,
>
> This patch series aims to use the memory terminologies described in
> include/linux/mm.h [1] for Linux xen code.
>
> Linux is using mistakenly MFN when GFN is meant, I suspect this is because the
> first support of Xen was for PV. This has
On 06/04/2015 12:55 PM, Rusty Russell wrote:
>
> Yeah, hard cases make bad law.
>
> I'm not too unhappy with this fix; ideally we'd rename save_fl and
> restore_fl to save_eflags_if and restore_eflags_if too.
>
I would be fine with this... but please document what the bloody
semantics of pvops
On 06/03/2015 02:31 AM, Andrew Cooper wrote:
> There appears to be no formal statement of what pv_irq_ops.save_fl() is
> supposed to return precisely. Native returns the full flags, while lguest and
> Xen only return the Interrupt Flag, and both have comments by the
> implementations stating that
On 06/23/2014 06:08 AM, Konrad Rzeszutek Wilk wrote:
> On Wed, Mar 19, 2014 at 08:02:22AM -0700, H. Peter Anvin wrote:
>> On 03/19/2014 06:21 AM, Konrad Rzeszutek Wilk wrote:
>>>>
>>>> The following patch does the always eager allocation. It's a
On 12/10/2014 05:03 PM, Luis R. Rodriguez wrote:
>
> This is an issue onloy for for non*-preemptive kernels.
>
> Some of Xen's hypercalls can take a long time and unfortunately for
> *non*-preemptive kernels this can be quite a bit of an issue.
> We've handled situations like this with cond_resch
On 12/10/2014 03:34 PM, Luis R. Rodriguez wrote:
> diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
> index 344b63f..40b5c0c 100644
> --- a/arch/x86/kernel/entry_32.S
> +++ b/arch/x86/kernel/entry_32.S
> @@ -982,7 +982,28 @@ ENTRY(xen_hypervisor_callback)
> ENTRY(xen_do_upcall)
66 matches
Mail list logo
