* Juergen Gross wrote:
> On 16.10.23 16:29, Peter Zijlstra wrote:
> > On Mon, Oct 16, 2023 at 02:39:32PM +0200, Juergen Gross wrote:
> > > Instead of stacking alternative and paravirt patching, use the new
> > > ALT_FLAG_CALL flag to switch those mixed calls to pure alternative
> > > handling.
* Masahiro Yamada wrote:
> This series reverts the in-kernel workarounds for inlining issues.
>
> The commit description of 77b0bf55bc67 mentioned
> "We also hope that GCC will eventually get fixed,..."
>
> Now, GCC provides a solution.
>
> https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.htm
* Yi Wang wrote:
> We may get -Wmissing-prototypes warnings when building
> kernel with W=1, it's better to fix them as global function
> signature can be changed and caller who use the old unchanged
> prototypes will be hosed.
>
> This patch fixes most of -Wmissing-prototypes warnings which
>
* wang.y...@zte.com.cn wrote:
> Hi Ingo,
>
> > * Yi Wang wrote:
> >
> > > We may get -Wmissing-prototypes warnings when building
> > > kernel with W=1, it's better to fix them as global function
> > > signature can be changed and caller who use the old unchanged
> > > prototypes will be hosed.
* Richard Biener wrote:
> Can kernel folks give this a second and third thought please so we
> don't implement sth that in the end won't satisfy you guys?
So this basically passes '0 size' to the inliner, which should be better
than passing in the explicit size, as we'd inevitably get it wrong
* Segher Boessenkool wrote:
> On Mon, Oct 08, 2018 at 11:07:46AM +0200, Richard Biener wrote:
> > On Mon, 8 Oct 2018, Segher Boessenkool wrote:
> > > On Sun, Oct 07, 2018 at 03:53:26PM +, Michael Matz wrote:
> > > > On Sun, 7 Oct 2018, Segher Boessenkool wrote:
> > > > > On Sun, Oct 07, 201
* Michael Matz wrote:
> (without an built-in assembler which hopefully noone proposes).
There are disadvantages (the main one is having to implement it), but a
built-in assembler has
numerous advantages as well:
- Better optimizations: for example -Os could more accurately estimate true
i
* Segher Boessenkool wrote:
> > > More precise *size* estimates, yes. And if the user lies he should not
> > > be surprised to get assembler errors, etc.
> >
> > Yes.
> >
> > Another option would be if gcc parses the inline asm directly and
> > does a more precise size estimation. Which is a
* Nadav Amit wrote:
> Ping.
Masahiro Yamada noted that some Reviewed-by tags were not added - could you
please double check
past mails and add them and re-send against the latest kernel?
Thanks,
Ingo
___
Virtualization mailing list
Virtua
* Nadav Amit wrote:
> > I ran some limited number of benchmarks, and in general the performance
> > impact is not very notable. You can still see >10 cycles shaved off some
> > syscalls that manipulate page-tables (e.g., mprotect()), in which
> > paravirt caused many functions not to be inlined
* Nick Desaulniers wrote:
> On Thu, Jun 21, 2018 at 7:24 PM Ingo Molnar wrote:
> > * Nick Desaulniers wrote:
> >
> > > native_save_fl() is marked static inline, but by using it as
> > > a function pointer in arch/x86/kernel/paravirt.c, it MUST be outlined.
* Nick Desaulniers wrote:
> native_save_fl() is marked static inline, but by using it as
> a function pointer in arch/x86/kernel/paravirt.c, it MUST be outlined.
> --- a/arch/x86/include/asm/irqflags.h
> +++ b/arch/x86/include/asm/irqflags.h
> @@ -13,7 +13,7 @@
> * Interrupt control:
> */
* Nick Desaulniers wrote:
> On Thu, Jun 14, 2018 at 5:17 PM H. Peter Anvin wrote:
> >
> > On 06/14/18 13:59, Nick Desaulniers wrote:
> > > On Thu, Jun 14, 2018 at 1:48 PM H. Peter Anvin wrote:
> > >>
> > >> On 06/13/18 14:05, Nick Desaulniers wrote:
> > >>> From: "H. Peter Anvin"
> > >>>
> >
| 38 ++
> mm/page_alloc.c | 4
> 6 files changed, 31 insertions(+), 16 deletions(-)
Acked-by: Ingo Molnar
Thanks,
Ingo
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
> header files).
>
> Signed-off-by: Randy Dunlap
Nice find:
Reviewed-by: Ingo Molnar
I agree that it needs to go through 0-day to find any hidden dependencies we
might
have grown due to this.
Thanks,
Ingo
__
* Quan Xu wrote:
>
>
> On 2017/11/13 23:08, Ingo Molnar wrote:
> > * Quan Xu wrote:
> >
> > > From: Quan Xu
> > >
> > > To reduce the cost of poll, we introduce three sysctl to control the
> > > poll time when running as a virtua
* Quan Xu wrote:
> From: Quan Xu
>
> To reduce the cost of poll, we introduce three sysctl to control the
> poll time when running as a virtual machine with paravirt.
>
> Signed-off-by: Yang Zhang
> Signed-off-by: Quan Xu
> ---
> Documentation/sysctl/kernel.txt | 35 +
* Juergen Gross wrote:
> On 23/06/17 18:23, Anton Vasilyev wrote:
> > The patch removes unnecessary return from void function.
> >
> > Found by Linux Driver Verification project (linuxtesting.org).
> >
> > Signed-off-by: Anton Vasilyev
>
> Reviewed-by: Juergen Gross
Cleanup is already upst
* Thomas Garnier wrote:
> >>*/
> >> - cmpq$.Lentry_SYSCALL_64_after_fastpath_call, (%rsp)
> >> + leaq.Lentry_SYSCALL_64_after_fastpath_call(%rip), %r11
> >> + cmpq%r11, (%rsp)
> >> jne 1f
> > This patch seems to add extra overhead to the syscall fast-pa
* 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-by: Thomas Ga
* 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.
> diff --git a/arch/x86/cryp
* Michael S. Tsirkin wrote:
> On Thu, Sep 08, 2016 at 08:49:43AM +0200, Ingo Molnar wrote:
> >
> > * Amit Shah wrote:
> >
> > > On (Tue) 30 Aug 2016 [08:04:15], Andy Lutomirski wrote:
> > > > virtio_console uses a small DMA buffer for control req
* Amit Shah wrote:
> On (Tue) 30 Aug 2016 [08:04:15], Andy Lutomirski wrote:
> > virtio_console uses a small DMA buffer for control requests. Move
> > that buffer into heap memory.
> >
> > Doing virtio DMA on the stack is normally okay on non-DMA-API virtio
> > systems (which is currently most
* Juergen Gross wrote:
> On 08/31/2015 02:05 AM, Rusty Russell wrote:
> >Juergen Gross writes:
> >>Ping?
> >
> >Acked-by: Rusty Russell
>
> Anyone willing to take this patch?
I wasn't Cc:-ed to the submission, please resend it with the Acked-by added.
Thanks,
Ingo
_
* Juergen Gross wrote:
> On 05/05/2015 07:21 PM, Jeremy Fitzhardinge wrote:
> >On 05/03/2015 10:55 PM, Juergen Gross wrote:
> >>I did a small measurement of the pure locking functions on bare metal
> >>without and with my patches.
> >>
> >>spin_lock() for the first time (lock and code not in cac
* Christian Borntraeger wrote:
> > By all means!
> >
> > You'll first need to cherry-pick these commits:
>
> > 927609d622a3 kernel: tighten rules for ACCESS ONCE
> > c5b19946eb76 kernel: Fix sparse warning for ACCESS_ONCE
> > dd36929720f4 kernel: make READ_ONCE() valid on const arguments
>
* Greg KH wrote:
> > >It's:
> > >
> > > d6abfdb20223 x86/spinlocks/paravirt: Fix memory corruption on unlock
> >
> > Yes, This is the original patch. Please note I have taken out the
> > READ_ONCE changes from the original patch to avoid build warnings
> > mentioned below.
> > (Those READ_ONCE
* Greg KH wrote:
> On Tue, Feb 24, 2015 at 02:54:59PM +0530, Raghavendra K T wrote:
> > Paravirt spinlock clears slowpath flag after doing unlock.
> > As explained by Linus currently it does:
> > prev = *lock;
> > add_smp(&lock->tickets.head, TICKET_LOCK_INC);
> >
* Jiri Olsa wrote:
>
> hi Ingo,
> please consider pulling
>
> thanks,
> jirka
>
>
> The following changes since commit 3617660e4e1618a888a2e3a4067224534302cb33:
>
> Merge tag 'perf-core-for-mingo' of
> git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf into perf/core
> (2014-05-01
* Waiman Long wrote:
> On 04/18/2014 03:46 AM, Ingo Molnar wrote:
> >* Waiman Long wrote:
> >
> >>On 04/17/2014 11:58 AM, Peter Zijlstra wrote:
> >>>On Thu, Apr 17, 2014 at 11:03:57AM -0400, Waiman Long wrote:
> >>>>+static __always_inline vo
* Waiman Long wrote:
> On 04/17/2014 11:58 AM, Peter Zijlstra wrote:
> >On Thu, Apr 17, 2014 at 11:03:57AM -0400, Waiman Long wrote:
> >>+static __always_inline void
> >>+clear_pending_set_locked(struct qspinlock *lock, u32 val)
> >>+{
> >>+ struct __qspinlock *l = (void *)lock;
> >>+
> >>+
* Waiman Long wrote:
> Because the qspinlock needs to touch a second cacheline; add a pending
> bit and allow a single in-word spinner before we punt to the second
> cacheline.
>
> Signed-off-by: Peter Zijlstra
> Signed-off-by: Waiman Long
This patch should have a "From: Peter" in it as well
* Waiman Long wrote:
> On 04/04/2014 12:57 PM, Konrad Rzeszutek Wilk wrote:
> >On Fri, Apr 04, 2014 at 03:00:12PM +0200, Peter Zijlstra wrote:
> >>So I'm just not ever going to pick up this patch; I spend a week trying
> >>to reverse engineer this; I posted a 7 patch series creating the
> >>equi
* Waiman Long wrote:
> On 04/04/2014 09:00 AM, Peter Zijlstra wrote:
> >
> > So I'm just not ever going to pick up this patch; I spend a week
> > trying to reverse engineer this; I posted a 7 patch series
> > creating the equivalent, but in a gradual and readable fashion:
> >
> > http://lkml
* Masami Hiramatsu wrote:
> (2013/11/27 22:30), Ingo Molnar wrote:
> >
> > * Masami Hiramatsu wrote:
> >
> >> (2013/11/22 11:35), Masami Hiramatsu wrote:
> >>> (2013/11/21 16:29), Ingo Molnar wrote:
> >>>>
> >>>> * Mas
* Masami Hiramatsu wrote:
> +#ifdef CONFIG_KPROBES
> +/*
> + * Blacklist ganerating macro. Specify functions which is not probed
> + * by using this macro.
> + */
> +#define __NOKPROBE_SYMBOL(fname) \
> +static struct kprobe_blackpoint __used \
>
* Masami Hiramatsu wrote:
> (2013/11/22 11:35), Masami Hiramatsu wrote:
> > (2013/11/21 16:29), Ingo Molnar wrote:
> >>
> >> * Masami Hiramatsu wrote:
> >>
> >>> (2013/11/21 2:36), Frank Ch. Eigler wrote:
> >>
> >> [ ... ]
>
* Masami Hiramatsu wrote:
> Use NOKPROBE_SYMBOL macro for protecting functions
> from kprobes instead of __kprobes annotation in
> dumpstack.c.
>
> Signed-off-by: Masami Hiramatsu
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: "H. Peter Anvin"
> Cc:
* Masami Hiramatsu wrote:
> (2013/11/21 2:36), Frank Ch. Eigler wrote:
[ ... ]
> > one needs to resort to something like:
> >
> > # cat /proc/kallsyms | grep ' [tT] ' | while read addr type symbol; do
> >perf probe $symbol
> > done
> >
> > then wait for a few hours for that to finish. The
* Frank Ch. Eigler wrote:
> masami.hiramatsu.pt wrote:
>
> > [...] This series also includes a change which prohibits probing
> > on the address in .entry.text because the code is used for very
> > low-level sensitive interrupt/syscall entries. Probing such code
> > may cause unexpected res
* Steven Rostedt wrote:
> On Tue, 12 Nov 2013 02:18:53 +0900
> Masami Hiramatsu wrote:
> >
> > > After that we can convert all the rest, probably as part of this series.
> >
> > OK, I'll do. :)
> > BTW, converting all the __kprobes involves many archs, which
> > kprobes ported. In that case,
* Masami Hiramatsu wrote:
> Currently the blacklist is maintained by hand in kprobes.c
> which is separated from the function definition and is hard
> to catch up the kernel update.
> To solve this issue, I've tried to implement new
> NOKPROBE_SYMBOL() macro for making kprobe blacklist at
> bu
* H. Peter Anvin wrote:
> Raghavendra...
>
> Even with this latest patch this branch is broken:
>
> :(.discard+0x6108): multiple definition of `__pcpu_unique_lock_waiting'
> arch/x86/xen/built-in.o:(.discard+0x23): first defined here
> CC drivers/firmware/google/gsmi.o
> arch/x86/kernel
* Gleb Natapov wrote:
> On Mon, Aug 05, 2013 at 11:46:03AM +0200, Ingo Molnar wrote:
> > Acked-by: Ingo Molnar
> >
> > I guess you'd want to carry this in the KVM tree or so - maybe in a
> > separate branch because it changes Xen as well?
>
> It ch
* Gleb Natapov wrote:
> On Fri, Aug 02, 2013 at 11:25:39AM +0200, Ingo Molnar wrote:
> > > Ingo,
> > >
> > > Do you have any concerns reg this series? please let me know if this
> > > looks good now to you.
> >
> > I'm incline
* Raghavendra K T wrote:
> On 07/31/2013 11:54 AM, Gleb Natapov wrote:
> >On Tue, Jul 30, 2013 at 10:13:12PM +0530, Raghavendra K T wrote:
> >>On 07/25/2013 03:08 PM, Raghavendra K T wrote:
> >>>On 07/25/2013 02:45 PM, Gleb Natapov wrote:
> On Thu, Jul 25, 2013 at 02:47:37PM +0530, Raghavend
* Raghavendra K T wrote:
> On 08/01/2013 02:34 PM, Raghavendra K T wrote:
> >On 08/01/2013 01:15 PM, Gleb Natapov wrote:
> >>>Shall I consider this as an ack for kvm part?
> >>>
> >>For everything except 18/18. For that I still want to see numbers. But
> >>18/18 is pretty independent from the re
* Kees Cook wrote:
> Make a copy of the IDT (as seen via the "sidt" instruction) read-only.
> This primarily removes the IDT from being a target for arbitrary memory
> write attacks, and has the added benefit of also not leaking the kernel
> base offset, if it has been relocated.
>
> We already
* Eric W. Biederman wrote:
> "H. Peter Anvin" writes:
>
> > On 04/08/2013 03:43 PM, Kees Cook wrote:
> >> This makes the IDT unconditionally read-only. This primarily removes
> >> the IDT from being a target for arbitrary memory write attacks. It has
> >> an added benefit of also not leaking (
* H. Peter Anvin wrote:
> On 04/09/2013 11:22 AM, Kees Cook wrote:
> >
> > Can we create a RO fixed per-cpu area?
> >
>
> "Fixed" and "percpu" are mutually exclusive...
There's a fixmap area that holds kmap_atomic() percpu mappings:
FIX_KMAP_BEGIN, /* reserved pte's for temporary ke
* Kees Cook wrote:
> > That's the area in which we just map 1:1 to memory. Anything allocated
> > with
> > e.g. kmalloc() ends up with those addresses.
>
> Ah-ha! Yes, I see now when comparing the debug/kernel_page_tables reports.
> It's
> just the High Kernel Mapping that we care about. A
* Avi Kivity wrote:
> > PS: Nikunj had experimented that pv-flush tlb +
> > paravirt-spinlock is a win on PLE where only one of them
> > alone could not prove the benefit.
>
> I'd like to see those numbers, then.
>
> Ingo, please hold on the kvm-specific patches, meanwhile.
I'll hold off on
* Raghavendra K T wrote:
> This series replaces the existing paravirtualized spinlock mechanism
> with a paravirtualized ticketlock mechanism. The series provides
> implementation for both Xen and KVM.(targeted for 3.5 window)
>
> Note: This needs debugfs changes patch that should be in Xen / l
* Andi Kleen wrote:
> > Care to back that up with numbers and proper trace evidence
> > instead of handwaving?
>
> E.g. my plumbers presentations on lock and mm scalability from
> last year has some graphs that show this very clearly, plus
> some additional data on the mutexes. This compares
ialization for
> >>>>> ‘xen_hypercall_names’)
> >>>>
> >>>> Oh, that I haven't seen. Can you send me the .config for that please.
> >>>
> >>> You can't be trying very hard then. I see lots of these (but no,
> >>
> &
* Randy Dunlap wrote:
> On Mon, 25 Jul 2011 16:25:42 +1000 Stephen Rothwell wrote:
>
> > Hi all,
>
> xen has lots of build errors and warnings (all on x86_64).
>
> CC arch/x86/xen/setup.o
> In file included from arch/x86/include/asm/xen/hypercall.h:42,
> from arch/x86/
* Jeremy Fitzhardinge wrote:
> On 10/26/2010 09:59 AM, Jeremy Fitzhardinge wrote:
> >
> > If the guest domain has been suspend/resumed or migrated, then the
> > system clock backing the pvclock clocksource may revert to a smaller
> > value (ie, can be non-monotonic across the migration/save-rest
* Jeremy Fitzhardinge wrote:
> On 09/22/09 11:02, Ingo Molnar wrote:
>
> > obviously they are workload dependent - that's why numbers were
> > posted in this thread with various workloads. Do you concur with
> > those conclusions that they are generally a speed
* Jeremy Fitzhardinge wrote:
> On 09/22/09 01:09, Ingo Molnar wrote:
> >>> kvm will be removing the pvmmu support soon; and Xen is talking about
> >>> running paravirtualized guests in a vmx/svm container where they don't
> >>> need most of the hooks
* Jeremy Fitzhardinge wrote:
> On 09/20/09 02:00, Avi Kivity wrote:
> > On 09/20/2009 10:52 AM, Arjan van de Ven wrote:
> >> On Sun, 20 Sep 2009 09:42:47 +0200
> >> Ingo Molnar wrote:
> >>
> >>
> >>> If we were able to rip out
* Alok Kataria wrote:
> Here is the patch which actually removes the vmi code.
>
> Signed-off-by: Alok N Kataria
> ---
>
> Documentation/kernel-parameters.txt |2
> arch/x86/Kconfig| 10
> arch/x86/include/asm/vmi.h | 269 --
> arch/x86/include/a
* Jiri Slaby wrote:
> To avoid a wrong compiler warning, use unitialized_var(cx) in
> xen_init_cpuid_mask.
>
> cx needn't be initialized for cpuid when ax is 1.
>
> Signed-off-by: Jiri Slaby
> Cc: Jeremy Fitzhardinge
> Cc: Chris Wright
> ---
> arch/x86/xen/enlighten.c |2 +-
> 1 files
* Laurent Vivier wrote:
> [PATCH 2/4] like for cpustat, introduce the "gtime" (guest time of
> the task) and "cgtime" (guest time of the task children) fields
> for the tasks. Modify signal_struct and task_struct. Modify
> /proc//stat to display these new fields.
> --- kvm.orig/include/linux
it's not worth moving them to another file).
Without this change, S3 resume on a kernel built with
CONFIG_CC_STACKPROTECTOR_ALL=y will fail.
Signed-off-by: Joseph Cihula
Cc: Arjan van de Ven
Cc: Tejun Heo
LKML-Reference: <49d13385.5060...@intel.com>
Signed-off-by: Ingo Molnar
---
* Arkadiusz Miskiewicz wrote:
> On Friday 03 of April 2009, Chris Wright wrote:
> > * Arkadiusz Miskiewicz (a.miskiew...@gmail.com) wrote:
> > > What about 9ea09af3bd3090e8349ca2899ca2011bd94cda85 ?
> > >
> > > stop_machine: introduce stop_machine_create/destroy.
> >
> > That is later fixed in a
* Rafael J. Wysocki wrote:
> On Thursday 02 April 2009, Chris Wright wrote:
> > * Rafael J. Wysocki (r...@sisk.pl) wrote:
> > > Sorry for the misunderstanding, I thought the breakage might be introduced
> > > between 15f7176eb1cccec0a332541285ee752b935c1c85 and
> > > 0a0c5168df270a50e3518e4f12bd
* Mike Travis wrote:
> Ingo Molnar wrote:
> > * Mike Travis wrote:
> >
> >> are available in the git repository at:
> >>
> >>
> >> git://git.kernel.org/pub/scm/linux/kernel/git/travis/linux-2.6-cpus4096-for-ingo.git
> >>
* Mike Travis wrote:
> are available in the git repository at:
>
>
> git://git.kernel.org/pub/scm/linux/kernel/git/travis/linux-2.6-cpus4096-for-ingo.git
>
> master
hm, when i tried to pull it, i got:
fatal: Couldn't find remote ref master
Ingo
* Yu Zhao <[EMAIL PROTECTED]> wrote:
> +static char *pci_assign_pio;
> +static char *pci_assign_mmio;
> +
> +static int pcibios_bus_resource_needs_fixup(struct pci_bus *bus)
> +{
> + int i;
> + int type = 0;
> + int domain, busnr;
> +
> + if (!bus->self)
> + return 0;
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
>> should never
>> be built with -pg (which ftrace does). Marking paravirt.o as
>> non-pg and marking all spinlock ops as always-inline solve the
>> hang.
>>
>
> Thanks Ingo, that would have taken me a while to work out.
yeah, i
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> the patches caused a boot hang with this config:
>
> http://redhat.com/~mingo/misc/config-Wed_Jul__9_14_47_04_CEST_2008.bad
ok, fixed it via the patch below.
Ingo
-->
commit 6412367fe22dc54cc727e7bec5bd65c36c1
the patches caused a boot hang with this config:
http://redhat.com/~mingo/misc/config-Wed_Jul__9_14_47_04_CEST_2008.bad
i have bisected it down to:
commit e17b58c2e85bc2ad2afc07fb8d898017c2b75ed1
Author: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Date: Mon Jul 7 12:07:53 2008 -0700
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> My experiments show that using a Xen-specific lock helps guest
> performance a bit (reduction in elapsed and system time in a kernbench
> run), but most significantly, reduces overall physical CPU consumption
> by 10%, and so increases overall
another small fixlet.
Ingo
->
commit 0ea0f032767f41fb0a9586ab6acb5c1408ef16c5
Author: Ingo Molnar <[EMAIL PROTECTED]>
Date: Wed Jul 9 14:39:15 2008 +0200
x86: paravirt spinlocks, modular build fix
fix:
MODPOST 408 modules
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> as there were no fundamental objections in this thread i've created a
> tip/x86/paravirt-spinlocks topic branch for these patches and started
> testing them.
small UP build fixes below.
Ingo
-
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> Jeremy Fitzhardinge wrote:
>> Linus Torvalds wrote:
>>
>>> On Fri, 20 Jun 2008, Ingo Molnar wrote:
>>>
>>>> okay - Jeremy, could you try the fix below? (or tip/master, i just
>&g
or tip/master, i just
pushed this out)
(i dont use gcc 3.x myself to build the kernel, had way too many
miscompilations in randconfig tests in the past.)
Ingo
-->
commit b68b80b8ab39c42707dc126c41e87d46edc97c27
Author: Ingo Molnar <[EMAIL PROTECTED]>
Date: Fri Jun 2
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> > On Thu, 19 Jun 2008, Ingo Molnar wrote:
> > >
> > > Below is the commit, it needed a small amount of massaging to apply the
> > > vo
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> On Thu, 19 Jun 2008, Ingo Molnar wrote:
> >
> > Below is the commit, it needed a small amount of massaging to apply the
> > void * -> unsigned long * change in the x86/bitops topic.
>
> Well, that's your b
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> config and crashlog can be found at:
>
> http://redhat.com/~mingo/misc/config-Thu_Jun_19_13_45_21_CEST_2008.bad
> http://redhat.com/~mingo/misc/crash-Thu_Jun_19_13_45_21_CEST_2008.log
just in case it helps, and for completeness,
anyway. I guarantee nothing. And if it
breaks, nobody saw me do anything. You can't prove this email wasn't sent
by somebody who is good at forging smtp.
This does require a gcc that is recent enough for "__builtin_constant_p()"
to work in an inline function, but
* Hugh Dickins <[EMAIL PROTECTED]> wrote:
> On Mon, 16 Jun 2008, Linus Torvalds wrote:
> > On Mon, 16 Jun 2008, Jeremy Fitzhardinge wrote:
> > >
> > > ptep_modify_prot_start() returns the current pte value, and puts the
> > > pte entry into a state where either the hardware will not update the
* Rusty Russell <[EMAIL PROTECTED]> wrote:
> > - /* Get the current pte state, but zero it out to make it
> > - non-present, preventing the hardware from asynchronously
> > - updating it. */
> > + /*
> > +* Get the current pte state, but zero it out to make it
> > +* non-pre
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> + /* Get the current pte state, but zero it out to make it
> +non-present, preventing the hardware from asynchronously
> +updating it. */
please use standard and consistent comment style, similar to:
> +/*
> + * Start a pte
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> +#define __HAVE_ARCH_PTEP_MODIFY_PROT_TRANSACTION
please turn this into CONFIG_ARCH_HAS_PTEP_MODIFY_PROT_TRANSACTION
instead.
Ingo
___
Virtualization mailing list
Virtualization@lists.linux-
* Ravikiran G Thirumalai <[EMAIL PROTECTED]> wrote:
> Would anyone have objection to have PARAVIRT depend on PCI, since the
> vsmp paravirt bits depend on PCI cfg space to determine if the system
> is vsmp? If not, this patch would suffice.
hm, that's not a good idea - there's nothing in lgue
* Glauber Costa <[EMAIL PROTECTED]> wrote:
> --- a/arch/x86/kernel/setup_64.c
> +++ b/arch/x86/kernel/setup_64.c
> @@ -346,6 +346,10 @@ #endif
> if (efi_enabled)
> efi_init();
>
> +#ifdef CONFIG_PARAVIRT
> + vsmp_init();
> +#endif
that #ifdef should be in setup.h,
* Glauber Costa <[EMAIL PROTECTED]> wrote:
> This series of five patches turns the vsmp architecture support in
> x86_64 into a paravirt client. If PARAVIRT is on, the probe function
> vsmp_init() is run unconditionally, patching the necessary irq
> functions accordingly if running ontop of su
* Glauber Costa <[EMAIL PROTECTED]> wrote:
> config X86_VSMP
> bool "Support for ScaleMP vSMP"
> depends on X86_64 && PCI
> - help
> + select PARAVIRT
> + help
hm, what's the idea here?
Ingo
___
Virtualization mailing
ivers/virtio/virtio_balloon.c:98: error: implicit declaration of function
'msleep'
the patch below fixes it.
Ingo
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
drivers/virtio/virtio_balloon.c |1 +
1 file changed, 1 insertion(
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
>> Maybe should this force-paravirt mode be a kernel debugging option?
>
> No, just a plain CONFIG_PARAVIRT to turn it on and off independently
> of everything else.
it should be a debugging option in the way that it's dependent on
KERNEL_DEBUG
* Glauber de Oliveira Costa <[EMAIL PROTECTED]> wrote:
> On Jan 18, 2008 8:02 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >
> > * Zachary Amsden <[EMAIL PROTECTED]> wrote:
> >
> > > > but in exchange you broke all of 32-bit with CONFIG_PARAVIRT
* Eduardo Habkost <[EMAIL PROTECTED]> wrote:
> This series contain fixes to make the paravirt_ops code compile and
> boot on x86_64.
>
> This is a follow-up for the previous series from Glauber.
thanks Eduardo, i've applied your fixes.
could you perhaps send the missing bits that add the miss
* Zachary Amsden <[EMAIL PROTECTED]> wrote:
> > but in exchange you broke all of 32-bit with CONFIG_PARAVIRT=y.
> > Which means you did not even build-test it on 32-bit, let alone boot
> > test it...
>
> Why are we rushing so much to do 64-bit paravirt that we are breaking
> working configura
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > The first fix is not even specific for PARAVIRT, and it's actually
> > preventing the whole tree from booting.
>
> on CONFIG_EFI, indeed :)
but in exchange you broke all of 32-bit with CONFIG_PARAVIRT=y. Which
means y
* Glauber de Oliveira Costa <[EMAIL PROTECTED]> wrote:
>
> This small series provides some more fixes towards the goal to have
> the PARAVIRT selectable for x86_64. After that, just some more small
> steps are needed.
thanks, applied.
> The first fix is not even specific for PARAVIRT, and it
* Alexey Dobriyan <[EMAIL PROTECTED]> wrote:
> > thanks, applied.
> >
> > btw., people have been talking about reducing the include file mess
> > for nearly a decade now,
>
> Some of us are actually doing it. ;-)
sorry, this was really not meant to slight your contributions in this
area in a
* Glauber de Oliveira Costa <[EMAIL PROTECTED]> wrote:
> This patch moves _set_gate and its users to desc.h. We can now use
> common code for x86_64 and i386.
a few days ago i started seeing weird crashes on 64-bit x86 in the
random-kernel-bootup tests. Nothing truly reproducable to be bisecta
* Glauber de Oliveira Costa <[EMAIL PROTECTED]> wrote:
> > > make[1]: *** No rule to make target
> > > `arch/x86/kernel/paravirt_patch_32.o', needed by
> > > `arch/x86/kernel/built-in.o'. Stop.
> >
> > if it's just that single missing file then please send me a patch that
> > adds that file an
* Glauber de Oliveira Costa <[EMAIL PROTECTED]> wrote:
> The core patching code for paravirt is sufficiently different
> among i386 and x86_64, and we move them to specific files.
this patch adds the paravirt_patch_32.o:
> -obj-$(CONFIG_PARAVIRT) += paravirt.o
> +obj-$(CONFIG_PARA
1 - 100 of 132 matches
Mail list logo
