>+cycle_t xen_clocksource_read(void)
>+{
>+ struct shadow_time_info *shadow = &get_cpu_var(shadow_time);
>+ cycle_t ret;
>+
>+ get_time_values_from_xen();
>+
>+ ret = shadow->system_timestamp + get_nsec_offset(shadow);
>+
>+ put_cpu_var(shadow_time);
>+
>+ return ret;
>>> Keir Fraser <[EMAIL PROTECTED]> 06.06.07 10:54 >>>
>On 6/6/07 09:39, "Jan Beulich" <[EMAIL PROTECTED]> wrote:
>
>> The issue is
>> that on that system, transition into ACPI mode takes over 600ms (SMM
>> execution, and hence no i
>> But I think that a clock source can be expected to be
>> monotonic anyway, which Xen's interpolation mechanism doesn't
>> guarantee across multiple CPUs. (I'm actually beginning to think that
>> this might also be the reason for certain test suites occasionally reporting
>> timeouts to fire ear
>>> Keir Fraser <[EMAIL PROTECTED]> 06.06.07 11:56 >>>
>On 6/6/07 10:30, "Jan Beulich" <[EMAIL PROTECTED]> wrote:
>
>>> If you have an ACPI PM timer in your system (and if you have SMM then your
>>> system is almost certainly modern
>>> Andi Kleen <[EMAIL PROTECTED]> 06.06.07 14:18 >>>
>
>>
>> Yes, this could be an issue. Is there any way to get an interrupt or MCE
>> when thermal throttling occurs?
>
>Yes you can get an thermal interrupt from the local APIC. See the Linux
>kernel source. Of course there would be still a race
in place
(CONFIG_KPROBES being removed here at once).
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
arch/i386/kernel/alternative.c | 67 +--
arch/i386/mm/init.c | 14 +---
arch/x86_64/kernel/vmlinux.lds.S |9 -
arch/x86
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
arch/i386/kernel/sysenter.c |4 +++-
1 files changed, 3 insertions(+), 1 deletion(-)
--- linux-2.6.22-rc7/arch/i386/kernel/sysenter.c2007-07-03
10:57:29.0 +0200
+++ 2.6.22-rc7-i386-in-gate-area/arch/i386/kernel/syse
>>> On x86-64 additionally remove all mappings past the kernel image, and
>>> remove leftovers from the removal of the more general (but abandoned)
>>> SMP alternatives.
>>>
>>
>>I'd already posted a patch to remove smp alternatives. I thought it had
>>been merged already, but I guess it's in
>>> Jeremy Fitzhardinge <[EMAIL PROTECTED]> 04.07.07 17:41 >>>
>Jan Beulich wrote:
>> Instead of suppressing the change of .text to become readonly, make
>> the SMP locks patching code properly adjust/restore the page access
>> rights.
>>
I have to admit that I don't see the point here - I can't seem to make any
sense of the OR... Jan
>>> Rusty Russell <[EMAIL PROTECTED]> 12.03.07 00:28 >>>
BUILD_BUG_ON_ZERO is named perfectly wrong, and BUILD_BUG_ON_RETURN_ZERO
is too long. Flip three bits, and the name is much more suitable.
S
Isn't defining these on i386 of at most historical value. The only consumer is
include/asm-generic/pgtable.h (ptep_clear_flush_{dirty,young}), and those are
already suppressed by __HAVE_ARCH_PTEP_CLEAR_{DIRTY,YOUNG}_FLUSH
being defined in include/asm-i386/pgtable.h. Or is there a particular need to
While the kernel headers provide for this, there don't appear to be any
in-tree users (which seems contrary to general Linux policies). Would there
be objections to remove all of these?
Jan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
>I've bisected it down to the x86_64-mm-cpa-kerneltext.patch and the
>
>+ if (!pte_present(*kpte))
>+ return 0;
I the most recent version of the patch I sent to Andi this line is gone (again),
as I realized it was wrong on i386 (namely for DEBUG_PAGEALLOC) and its
respective v
Various architectures define these, but they aren't being used anywhere -
candidates for removal? The more that (at least) on i386 and x86-64
pte_exprotect() is not symmetrical to pte_exec() and pte_mkexec()...
Jan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the b
>>> Jeremy Fitzhardinge <[EMAIL PROTECTED]> 16.03.07 06:10 >>>
>Zachary Amsden wrote:
>> Well testing that is not so fun. I installed SUSE Pro 9.0, and
>> strings on ld.so contains the magic at_sysinfo assert! But it doesn't
>> install TLS libraries, so I'll have to install them by hand.
>>
>> In
>>> Jeremy Fitzhardinge <[EMAIL PROTECTED]> 16.03.07 17:46 >>>
>Jan Beulich wrote:
>> I have one, too (which is one reasone why I created the original Xen patch).
>>
>
>It's some version of SuSE 9, right? What glibc version?
Yes. 2.3.2.
>>> Greg KH <[EMAIL PROTECTED]> 25.03.07 18:11 >>>
>On Sun, Mar 25, 2007 at 08:23:23AM -0700, Kevin P. Fleming wrote:
>> I just upgraded from 2.6.20.2 to 2.6.20.4 on my Compaq V6000 laptop,
>> which has an NVidia core chipset. It has the MCP51 and uses it for PATA
>> and SATA.
>>
>> Booting the 2.
sure
that both mappings (kernel image and 1:1 mapping) get updated here.
(Not sure what the symbol 'stext' is good for; can it be removed?)
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
--- linux-2.6.21-rc5/arch/i386/kernel/vmlinux.lds.S 2007-03-26
15:20:02.0 +0200
++
Based on replies to a respective query, remove the pci_dac_dma_...() APIs
(except for pci_dac_dma_supported() on Alpha, where this function is used
in non-DAC PCI DMA code).
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
Cc: Jesse Barnes <[EMAIL
Looking at both the i386 and x86-64 implementations I fail to understand why
there is an explicit requirement on calling global_flush_tlb() after
change_page_attr(), yet actual TLB flushing will not normally happen (on i386
it will happen if the CPU doesn't support clflush, but if it does, or on x8
>+static __cpuinit void reloc_dyn(Elf32_Ehdr *ehdr, unsigned offset)
>+{
>+ Elf32_Dyn *dyn = (void *)ehdr + offset;
>+
>+ for(; dyn->d_tag != DT_NULL; dyn++)
>+ switch(dyn->d_tag) {
>+ case DT_PLTGOT:
>+ case DT_HASH:
>+ case DT_STRTAB:
>>> Jeremy Fitzhardinge <[EMAIL PROTECTED]> 05.04.07 09:31 >>>
>Jan Beulich wrote:
>> While there's a certain level of control on what DT_* may appear in the
>> vDSO, not even considering other than the above types seems fragile to
>> me. Since fu
>+ for(; dyn->d_tag != DT_NULL; dyn++)
>+ switch(dyn->d_tag) {
>+ case DT_PLTGOT:
>+ case DT_HASH:
>+ case DT_STRTAB:
>+ case DT_SYMTAB:
>+ case DT_RELA:
>+ case DT_INIT:
>+ case DT_FINI:
>+
>>> Andi Kleen <[EMAIL PROTECTED]> 05.04.07 14:43 >>>
>On Thursday 05 April 2007 11:32:49 Jan Beulich wrote:
>> Looking at both the i386 and x86-64 implementations I fail to understand why
>> there is an explicit requirement on calling global_flush_tlb() afte
>Considering where it failed and that 2.6.20.3 worked, I would be
>extremely surprised if this wasn't one more report of
>adjust-legacy-ide-resource-setting.patch breaking booting (and we
>already have confirmed reports for this)...
>
>But AFAIK we still don't understand how this patch managed t
But why do you remove the printk()?
>>> "Tomita, Haruo" <[EMAIL PROTECTED]> 26.04.07 08:27 >>>
This patch fixes a typo in mod_init().
fwh_done is performed when Intel fwh is found.
intel-rng.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-2.6.21-rc7-mm1/drivers/char/hw_
>>> "Tomita, Haruo" <[EMAIL PROTECTED]> 26.04.07 08:56 >>>
>> But why do you remove the printk()?
>
>I think that FWH connected to LPC of ICHx are not only Intel products.
>For example, sst... etc.
>Does rng address differ in except Intel products?
I am not aware of non-Intel FWHs supporting the
>Ingo just raised this as an issue for paravirt_ops as well. I don't
>quite follow what's going on there. My understanding is that there are
>some old versions of glibc (which were unreleased CVS snapshots shipped
>by some vendors) which don't use the vdso's ELF header, but instead have
>their o
>>> Andi Kleen <[EMAIL PROTECTED]> 28.03.07 21:07 >>>
>
>> +#ifdef CONFIG_HOTPLUG_CPU
>> +/* It must still be possible to apply SMP alternatives. */
>> +if (num_possible_cpus() <= 1)
>
>It would be better to temporarily change the pages where the alternatives
>are applied while that is done
Under CONFIG_DISCONTIGMEM, assuming that a !pfn_valid() implies all
subsequent pfn-s are also invalid is wrong. Thus replace this by
explicitly checking against the E820 map.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
Acked-by: Mark Langsdorf <[EMAIL PROTECTED]>
--- linux-2.6
built.
Once at it, also eliminate false dependencies due to use of
...CONFIG_... identifiers.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
--- linux-2.6.21-rc5/scripts/basic/fixdep.c 2007-02-04 19:44:54.0
+0100
+++ 2.6.21-rc5-fixdep-mod/scripts/basic/fixdep.c2007-0
is good for; can it be removed?)
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
--- linux-2.6.21-rc5-ff/arch/i386/kernel/vmlinux.lds.S 2007-03-29
13:35:48.0 +0200
+++ 2.6.21-rc5-ff-x86-init-page-attribs/arch/i386/kernel/vmlinux.lds.S
2007-03-21 12:29:00.0 +0100
>>> Andi Kleen <[EMAIL PROTECTED]> 29.03.07 14:22 >>>
>On Thursday 29 March 2007 14:01, Jan Beulich wrote:
>> On x86-64, kernel memory freed after init can be entirely unmapped instead
>> of just getting 'poisoned' by overwriting with
>>> Randy Dunlap <[EMAIL PROTECTED]> 29.03.07 17:39 >>>
>> --- linux-2.6.21-rc5/scripts/basic/fixdep.c 2007-02-04 19:44:54.0
>> +0100
>> +++ 2.6.21-rc5-fixdep-mod/scripts/basic/fixdep.c 2007-03-29
>> 11:11:10.0 +0200
>> @@ -29,8 +29,7 @@
>> * option which is mentioned in an
>>> Randy Dunlap <[EMAIL PROTECTED]> 29.03.07 18:38 >>>
>On Thu, 29 Mar 2007 17:06:24 +0100 Jan Beulich wrote:
>
>> >>> Randy Dunlap <[EMAIL PROTECTED]> 29.03.07 17:39 >>>
>> >> --- linux-2.6.21-rc5/scripts/basic/fixdep.c
>>> Sam Ravnborg <[EMAIL PROTECTED]> 30.03.07 17:08 >>>
>On Thu, Mar 29, 2007 at 10:27:14AM +0100, Jan Beulich wrote:
>> Commit 2e3646e51b2d6415549b310655df63e7e0d7a080 changed the way
>> the split config tree is built, but failed to also adjust fixdep
>&
>> [] __put_user_4+0x12/0x18
>> DWARF2 unwinder stuck at __put_user_4+0x12/0x18
>> Leftover inexact backtrace:
>> [] ret_from_fork+0x6/0x1c
>
>Hmpf. I saw it once in child_rip here too. Then I wanted to reproduce it to
>report
>properly and couldn't again. I had a few other backtraces that were
duplicate
mappings don't exist, the same change is done there, too, both for
consistency and because checking pte_present() before using various other
pte_XXX functions is a requirement anyway. At once, i386 code gets
adjusted to use pte_huge() instead of open coding this.
Signed-off-by: Jan
redundant
conditional.
In ali-agp, add missing calls to global_flush_tlb().
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
--- linux-2.6.21-rc5/drivers/char/agp/ali-agp.c 2007-03-26 15:20:14.0
+0200
+++ 2.6.21-rc5-agp/drivers/char/agp/ali-agp.c 2007-03-30 13:33:03.0
+0200
@@
>+ testb $8, %dxl/* rdx is 3,5,6,7,9..15 */
Could you use the more conventional name %dl (or whatever is being meant)
here?
>+.L42:
>+ prefetchnta 128(%rsi)
I think I commented similarly on a previous version of the patch: This will
- result in still bringing the first 1
.
Version 2 did a little too much change - on x86-64 it duplicated a pte_present()
check already done, on i386 the similarly added check would have prevented
CONFIG_DEBUG_ALLOC from working.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
---
arch/i386/kernel/vmlinux.lds.S |4 ++--
arc
>>> Andi Kleen <[EMAIL PROTECTED]> 30.04.07 17:50 >>>
>
>From: Zachary Amsden <[EMAIL PROTECTED]>
>
>In situations where page table updates need only be made locally, and there is
>no cross-processor A/D bit races involved, we need not use the heavyweight
>xchg instruction to atomically fetch and c
>Prarit, Jan: here's the original patch plus the two fixups. Could you please
>re-review and ideally re-test this, let me know the result?
Works fine for me - ack. Jan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More maj
ently), remove it altogether rather than inventing
something like CC_CLOBBER (to accompany CC_SET/CC_OUT).
Signed-off-by: Jan Beulich
--- a/arch/x86/include/asm/rwsem.h
+++ b/arch/x86/include/asm/rwsem.h
@@ -154,7 +154,7 @@ static inline bool __down_write_trylock(
: "+m&
>>> On 13.07.16 at 14:53, wrote:
> On 13/07/16 13:20, Petr Tesarik wrote:
>> If a crash kernel is loaded, do not crash the running domain. This is
>> needed if the kernel is loaded with crash_kexec_post_notifiers, because
>> panic notifiers are run before __crash_kexec() in that case, and this
>>
>>> On 15.09.16 at 12:05, wrote:
> On 14/09/16 22:01, Kyle Huey wrote:
>> Xen advertises the underlying support for CPUID faulting but not does pass
>> through writes to the relevant MSR, nor does it virtualize it, so it does
>> not actually work. For now mask off the relevant bit on MSR_PLATFORM_
>>> On 26.10.17 at 21:29, wrote:
> On 26/10/17 19:49, Craig Bergstrom wrote:
>> Sander, thanks for the details, they've been very useful.
>>
>> I suspect that your host system's mem=2048M parameter is causing the
>> problem. Any chance you can confirm by removing the parameter and
>> running the
>>> On 31.08.15 at 21:19, wrote:
> On 08/20/2015 08:04 AM, Jan Beulich wrote:
>> While commit 4cca6ea04d31c claims to not have any functional effect on
>> Xen, this isn't the case: Before that change, kernels built without
>> CONFIG_XEN_PVHVM (a dependency whi
ZE, )
to return page-aligned memory blocks, I believe this needs to be
switched back to __get_free_page().
Signed-off-by: Jan Beulich
Cc: Andy Lutomirski
Cc: Boris Ostrovsky
Cc: David Vrabel
Cc: Konrad Rzeszutek Wilk
---
arch/x86/kernel/ldt.c |2 +-
1 file changed, 1 insertion(+), 1 delet
>>> On 01.09.15 at 21:37, wrote:
> On Tue, Sep 1, 2015 at 3:48 AM, Jan Beulich wrote:
>> While commit 37868fe113 ("x86/ldt: Make modify_ldt synchronous") added
>> a nice comment explaining that Xen needs page-aligned whole page chunks
>> for guest desc
ZE, )
to return page-aligned memory blocks, I believe this needs to be
switched back to __get_free_page().
Signed-off-by: Jan Beulich
Cc: Andy Lutomirski
Cc: Boris Ostrovsky
Cc: David Vrabel
Cc: Konrad Rzeszutek Wilk
---
v2: Also adjust the freeing side.
---
arch/x86/kernel/ldt.c |4 ++--
1
>>> On 02.09.15 at 16:08, wrote:
> On Sep 2, 2015 5:46 AM, "Jan Beulich" wrote:
>>
>> While commit 37868fe113 ("x86/ldt: Make modify_ldt synchronous") added
>> a nice comment explaining that Xen needs page-aligned whole page chunks
>>
ZE, )
to return page-aligned memory blocks, I believe this needs to be
switched back to __get_free_page() (or better get_zeroed_page()).
Signed-off-by: Jan Beulich
Cc: Andy Lutomirski
Cc: Boris Ostrovsky
Cc: David Vrabel
Cc: Konrad Rzeszutek Wilk
---
v3: Use get_zeroed_page() and free_page
>>> On 04.09.15 at 01:54, wrote:
> If I undestand this correctly then I think we're in a pickle with Xen unless
> we add hypervisor support and hypercall support for mtrr_type_lookup().
Are you perhaps unaware of XENPF_read_memtype (which our kernel
uses)?
Jan
--
To unsubscribe from this list:
Use bool instead of u8 or plain int where applicable. Also use u32 or
unsigned int instead of unsigned long when a 32-bit type suffices,
generating slightly better code on x86-64.
Signed-off-by: Jan Beulich
---
arch/x86/include/asm/hpet.h|6 +++---
arch/x86/kernel/early-quirks.c |2
>>> On 19.10.15 at 16:51, wrote:
> Signed-off-by: Michal Sojka
Oops - yes of course. Thanks.
Reviewed-by: Jan Beulich
> --- a/scripts/kconfig/expr.c
> +++ b/scripts/kconfig/expr.c
> @@ -1113,7 +1113,7 @@ void expr_print(struct expr *e, void (*fn)(void *,
> str
>>> On 19.10.15 at 18:25, wrote:
> On 10/19/2015 06:16 AM, John Doe wrote:
[0.00] general protection fault: [#1] SMP
[0.00] Modules linked in:
[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted
> 4.1.9-6.pvops.qubes.x86_64 #1
[0.00] Hardware na
>>> On 20.10.15 at 15:22, wrote:
> The reason I think its this commit is that RAX, RDX and RCX look very
> much like arguments to xsetbv (which xstate_enable_boot_cpu() executes)
> and RAX value is 0x1f, which has two new bits that this commit defined.
That would be the two MPX related bits, ye
>>> On 20.10.15 at 16:27, wrote:
> On 10/20/2015 09:43 AM, Jan Beulich wrote:
>>>>> On 20.10.15 at 15:22, wrote:
>>> The reason I think its this commit is that RAX, RDX and RCX look very
>>> much like arguments to xsetbv (which xstate_enable_boot_cpu
Omitting suffixes from instructions in AT&T mode is bad practice when
operand size cannot be determined by the assembler from register
operands, and is likely going to be warned about by upstream gas in the
future (mine does already). Add the single missing suffix here.
Signed-off-by: Jan Beu
Add missing insn suffixes and use rmwcc.h just like was (more or less)
recently done for bitops.h as well.
Signed-off-by: Jan Beulich
---
arch/x86/include/asm/sync_bitops.h | 34 --
1 file changed, 12 insertions(+), 22 deletions(-)
--- 4.18-rc2/arch/x86
Some Intel CPUs don't recognize 64-bit XORs as zeroing idioms - use
32-bit ones instead.
Signed-off-by: Jan Beulich
---
arch/x86/crypto/aegis128-aesni-asm.S |2 +-
arch/x86/crypto/aegis128l-aesni-asm.S|2 +-
arch/x86/crypto/aegis256-aesni-asm.S |2 +-
arch/x86/c
>>> On 11.04.18 at 09:08, wrote:
> On 14/03/18 09:48, Jan Beulich wrote:
>>>>> On 26.02.18 at 15:08, wrote:
>>> @@ -35,6 +40,9 @@ void xen_arch_post_suspend(int cancelled)
>>>
>>> static void xen_vcpu_notify_restore(void *da
>>> On 11.04.18 at 13:53, wrote:
> * Jan Beulich wrote:
>
>> Additionally, x86 maintainers: is there a particular reason this (or
>> any functionally equivalent patch) isn't upstream yet? As indicated
>> before, I had not been able to find any discussion,
>>> On 12.04.18 at 09:32, wrote:
> * Jan Beulich wrote:
>
>> >>> On 11.04.18 at 13:53, wrote:
>> > * Jan Beulich wrote:
>> >
>> >> Additionally, x86 maintainers: is there a particular reason this (or
>> >> any functio
>>> On 26.02.18 at 15:08, wrote:
> @@ -35,6 +40,9 @@ void xen_arch_post_suspend(int cancelled)
>
> static void xen_vcpu_notify_restore(void *data)
> {
> + if (xen_pv_domain() && boot_cpu_has(X86_FEATURE_SPEC_CTRL))
> + wrmsrl(MSR_IA32_SPEC_CTRL, this_cpu_read(spec_ctrl));
> +
>
Add missing insn suffixes and use rmwcc.h just like was (more or less)
recently done for bitops.h as well.
Signed-off-by: Jan Beulich
---
v2: Re-base over rmwcc.h changes.
---
arch/x86/include/asm/sync_bitops.h | 31 +--
1 file changed, 9 insertions(+), 22
>>> On 21.11.18 at 12:55, wrote:
> From: Jan Beulich
>> Sent: 21 November 2018 10:11
>>
>> Add missing insn suffixes and use rmwcc.h just like was (more or less)
>> recently done for bitops.h as well.
>
> Why? bts (etc) on memory don't re
>>> On 21.11.18 at 14:49, wrote:
> From: Jan Beulich
>> Sent: 21 November 2018 13:03
>>
>> >>> On 21.11.18 at 12:55, wrote:
>> > From: Jan Beulich
>> >> Sent: 21 November 2018 10:11
>> >>
>> >> Add missin
Some Intel CPUs don't recognize 64-bit XORs as zeroing idioms. Zeroing
idioms don't require execution bandwidth, as they're being taken care
of in the frontend (through register renaming). Use 32-bit XORs instead.
Signed-off-by: Jan Beulich
---
v2: Explain what zeroing idiom
ister operands, and is likely going to be warned about by upstream
gas in the future (mine does already). Add the other missing suffixes
here as well.
Signed-off-by: Jan Beulich
---
arch/x86/entry/entry_64.S |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- 4.18-rc3/arch/x86/en
>>> On 03.07.18 at 10:46, wrote:
> From: Jan Beulich
>> Sent: 03 July 2018 09:36
> ...
>> As said there, omitting suffixes from instructions in AT&T mode is bad
>> practice when operand size cannot be determined by the assembler from
>> register operands
>>> On 09.07.18 at 10:33, wrote:
> Anyway, normally assembler is the one who chooses instruction
> encoding.
There are different possible views here, and I personally think that
while it is a compiler's job to chose optimal encodings, assemblers
shouldn't by default alter what the programmer (or
>>> On 25.06.18 at 18:33, wrote:
> On 06/25/2018 03:25 AM, Jan Beulich wrote:
>> Some Intel CPUs don't recognize 64-bit XORs as zeroing idioms - use
>> 32-bit ones instead.
>
> Hmph. Is that considered a bug (errata)?
No.
> URL/references?
Intel'
>>> On 26.06.18 at 09:18, wrote:
> * Jan Beulich wrote:
>
>> Add missing insn suffixes and use rmwcc.h just like was (more or less)
>> recently done for bitops.h as well.
>>
>> Signed-off-by: Jan Beulich
>> ---
>>> On 08.05.18 at 04:38, wrote:
> On Mon, May 7, 2018 at 5:16 AM Jan Beulich wrote:
>
>> While on native entry into the kernel happens on the trampoline stack,
>> PV Xen kernels are being entered with the current thread stack right
>> away. Hence source and de
>>> On 09.05.18 at 22:33, wrote:
> @@ -64,6 +67,17 @@ ENTRY(pvh_start_xen)
> mov %eax,%es
> mov %eax,%ss
>
> + /* Set base address in stack canary descriptor. */
> + movl _pa(gdt_start),%eax
> + movl $_pa(canary),%ecx
> + movw %cx, (PVH_GDT_ENTRY_CANARY * 8) + 0(%eax)
>>> On 16.05.18 at 18:44, wrote:
> Jan Beulich wrote:
>>>>> On 15.05.18 at 16:11, wrote:
>>> --- a/arch/x86/include/asm/refcount.h
>>> +++ b/arch/x86/include/asm/refcount.h
>>> @@ -14,34 +14,43 @@
>>> * central refcount exception
>>> On 17.05.18 at 16:47, wrote:
> @@ -64,6 +67,9 @@ ENTRY(pvh_start_xen)
> mov %eax,%es
> mov %eax,%ss
>
> + mov $PVH_CANARY_SEL,%eax
> + mov %eax,%gs
I doubt this is needed for 64-bit (you could equally well load zero or leave
in place what's there in that case), and loadi
>>> On 17.05.18 at 19:47, wrote:
> On 05/17/2018 11:02 AM, Jan Beulich wrote:
>>>>> On 17.05.18 at 16:47, wrote:
>>> @@ -64,6 +67,9 @@ ENTRY(pvh_start_xen)
>>> mov %eax,%es
>>> mov %eax,%ss
>>>
>>> + mov $PVH_C
>>> On 12.12.18 at 08:06, wrote:
> On Wed, Dec 05, 2018 at 09:01:33AM -0500, Boris Ostrovsky wrote:
>>On 12/5/18 4:32 AM, Roger Pau Monné wrote:
>>> On Wed, Dec 05, 2018 at 10:19:17AM +0800, Chao Gao wrote:
I find some pass-thru devices don't work any more across guest reboot.
Assigning
>>> On 12.12.18 at 16:18, wrote:
> On Wed, Dec 12, 2018 at 01:51:01AM -0700, Jan Beulich wrote:
>>>>> On 12.12.18 at 08:06, wrote:
>>> On Wed, Dec 05, 2018 at 09:01:33AM -0500, Boris Ostrovsky wrote:
>>>>On 12/5/18 4:32 AM, Roger Pau Monné wrote
>>> On 13.12.18 at 04:46, wrote:
> On Wed, Dec 12, 2018 at 08:21:39AM -0700, Jan Beulich wrote:
>>>>> On 12.12.18 at 16:18, wrote:
>>> On Wed, Dec 12, 2018 at 01:51:01AM -0700, Jan Beulich wrote:
>>>>>>> On 12.12.18 at 08:06, wro
Change kconfig behavior so that mixing bool and tristate config
settings in a choice is possible and has the desired effect of
offering just the tristate options individually if the choice gets set
to M, and a normal boolean selection if the choice gets set to Y.
Signed-off-by: Jan Beulich
Miscellaneous x86 stuff that can live in .rodata.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
arch/i386/kernel/alternative.c | 30 +++---
arch/i386/kernel/smpboot.c |4
arch/i386/kernel/trampoline.S |4
arch/i386/mach-v
.. as they're never written to.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
arch/i386/kernel/traps.c|6 +++---
arch/x86_64/kernel/stacktrace.c |2 +-
arch/x86_64/kernel/traps.c |4 ++--
include/asm-x86_64/stacktrace.h |2 +-
4 files changed, 7 inser
.. as they're, with a single exception, never written to.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
arch/i386/kernel/cpu/perfctr-watchdog.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
--- linux-2.6.23-rc5/arch/i386/kernel/cpu/perfctr-watchdog.c200
Add support for and use the multi-byte NOPs recently documented to be
available on all PentiumPro and later processors.
This patch only applies cleanly on top of the "x86: misc.
constifications" patch sent earlier.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
arch/i386/kern
>>> Andrew Morton <[EMAIL PROTECTED]> 25.09.07 18:08 >>>
>On Tue, 25 Sep 2007 13:53:51 +0200 "Rafael J. Wysocki" <[EMAIL PROTECTED]>
>wrote:
>
>> Hi,
>>
>> This patch from Andi:
>>
>> x86_64-mm-cpa-einval.patch
>>
>> makes the hda_intel audio driver stop working on my HP nx6325.
>>
>> The foll
Otherwise 'modprobe -r' on a module having a dependency on bridge will
implicitly unload bridge, bringing down all connectivity that was using
bridges.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
net/bridge/br_if.c |9 +
1 file changed, 9 insertions(+)
--- linu
>>> Stephen Hemminger <[EMAIL PROTECTED]> 26.09.07 19:12 >>>
>On Wed, 26 Sep 2007 17:08:19 +0100
>"Jan Beulich" <[EMAIL PROTECTED]> wrote:
>
>> >>> Stephen Hemminger <[EMAIL PROTECTED]> 26.09.07 17:37 >>>
>
>> >Sounds like a module utilities problem since unloading one module doesn't
>> >normally unload others.
>>
>> I have to disagree here - 'modprobe -r' is specifically unloading all
>> modules the
>> specified one references as long as they have a use count of zero. The
>> difference to other net
>>> Roman Zippel <[EMAIL PROTECTED]> 16.09.07 19:29 >>>
>On Mon, 10 Sep 2007, Jan Beulich wrote:
>
>> --- linux-2.6.23-rc5/scripts/kconfig/menu.c 2007-09-07 16:48:23.0
>> +0200
>> +++ 2.6.23-rc5-tristate-choices/scripts/kconfig/menu
>>> Andrew Morton <[EMAIL PROTECTED]> 16.09.07 12:18 >>>
>On Mon, 10 Sep 2007 14:02:17 +0100 "Jan Beulich" <[EMAIL PROTECTED]> wrote:
>
>> .. as they're never written to.
>
>arch/i386/kernel/traps.c: In function 'dump_tra
-off-by: Jan Beulich <[EMAIL PROTECTED]>
arch/i386/mm/pgtable.c |3 +--
1 files changed, 1 insertion(+), 2 deletions(-)
--- linux-2.6.23-rc6/arch/i386/mm/pgtable.c 2007-09-14 17:38:47.0
+0200
+++ 2.6.23-rc6-i386-set-fixmap/arch/i386/mm/pgtable.c 2007-09-19
10:49:53.000
It doesn't seem to make sense to hide these, even if their counts
can't change at the point in time they're being displayed.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
arch/i386/kernel/irq.c | 18 ++
arch/x86_64/kernel/irq.c | 18 ++
, in the ideal
case allow just all the -Wa,* options to pass through.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
---
Makefile| 15 ++--
scripts/Makefile.build | 51 +++-
scripts/Makefile.modinst|2 -
sc
tested with.
The patch also does away with the need to special case the kallsyms-
internal symbols by making them available even in the first linking
stage.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
---
Makefile | 44 +---
init/K
>>> Andi Kleen <[EMAIL PROTECTED]> 19.09.07 18:09 >>>
>On Wednesday 19 September 2007 16:39:39 Jan Beulich wrote:
>> One more of these issues (which were considered fixed a few releases
>> back): Other than on x86-64, i386 allows set_fixmap() to replace
&g
>@@ -162,7 +198,7 @@ __change_page_attr(unsigned long address
> /* on x86-64 the direct mapping set at boot is not using 4k pages */
> BUG_ON(PageReserved(kpte_page));
>
>- save_page(kpte_page);
>+ save_page(kpte_page, 0);
> if (page_private(kpte_page) == 0)
>
601 - 700 of 1374 matches
Mail list logo
