>>> On 04.07.14 at 08:12, Jan Beulich wrote:
>>>> On 04.07.14 at 01:11, wrote:
> > From: Greg Kroah-Hartman
> >
> > Jan points out that I forgot to make the needed fixes to the
> > lz4_uncompress_unknownoutputsize() function to mirror the changes
>>> On 11.07.14 at 00:58, wrote:
> On 07/03/2014 07:35 AM, Jan Beulich wrote:
>> Relying on static functions used just once to get inlined (and
>> subsequently have dead code paths eliminated) is wrong: Compilers are
>> free to decide whether they do this, re
>>> On 16.07.14 at 17:19, wrote:
> Hi Jan, Michal,
>
> I am not sure who maintains genksyms officially, so I am sending this
> question to the two of you as folks who seemed to have contributed to the
> tool. :-)
>
> I noticed with genksyms that a symbol is opaquely defined in a
> public header
passed to xenbus_dev_fatal(); -EILSEQ, -ENODATA, or
-EPROTO (despite it normally being network specific) would seem
better to me.
In any event
Reviewed-by Jan Beulich
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vge
> Signed-off-by: Daeseok Youn
Reviewed-by: Jan Beulich
albeit the solution is not ideal:
> --- a/drivers/xen/xen-pciback/vpci.c
> +++ b/drivers/xen/xen-pciback/vpci.c
> @@ -130,6 +130,7 @@ static int __xen_pcibk_add_pci_dev(struct
> xen_pcibk_device *pdev,
>
gt; Signed-off-by: Daeseok Youn
As before
Reviewed-by: Jan Beulich
> ---
> v2: The kfree() invocation is moved outside the locked region.
>
> drivers/xen/xen-pciback/vpci.c |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/xen/xen
>>> "George Spelvin" 05/28/14 4:40 PM >>>
>Jan: Is support for SLE10's pre-2.18 binutils still required?
>Your PEXTRD fix was only a year ago, so I expect, but I wanted to ask.
I'd much appreciate if I would be able to build the kernel that way for another
while.
>Two other minor additional cha
>>> "George Spelvin" 05/28/14 11:47 PM >>>
>Jan Beulich wrote:
>> "George Spelvin" 05/28/14 4:40 PM
>>> Jan: Is support for SLE10's pre-2.18 binutils still required?
>>> Your PEXTRD fix was only a year ago, so I expect, but
en regions
get unmapped, this is being fixed at once along with adding a similar
check to swiotlb_tbl_sync_single().
Obviously the less intrusive change would be to simply drop the check in
swiotlb_tbl_unmap_single().
Signed-off-by: Jan Beulich
---
lib/swiotlb.c | 28 ++
ome Fujitsu system (with possibly not up to date
firmware, but anyway).
Perhaps efi_read_alarm() should not fail if neither enabled nor pending
are set, but the returned time is invalid?
Reported-by: Raymund Will
Signed-off-by: Jan Beulich
---
drivers/rtc/rtc-efi.c |
>>> On 20.06.14 at 23:29, wrote:
> --- a/drivers/firmware/efi/efi.c
> +++ b/drivers/firmware/efi/efi.c
> @@ -298,7 +298,7 @@ int __init efi_config_init(efi_config_table_type_t
> *arch_tables)
> if (table64 >> 32) {
> pr_cont("\n");
>
>>> On 23.06.14 at 11:53, wrote:
> On 20/06/14 22:29, Daniel Kiper wrote:
>> Do not access EFI memory map if it is not available. At least
>> Xen dom0 EFI implementation does not have an access to it.
>
> Could it make one based on the XENMEM_memory_map or
> XENMEM_machine_memory_map hypercall?
space: path).
Also remove a bogus commented out annotation - there's no register
%orig_rax after all.
Signed-off-by: Jan Beulich
---
arch/x86/kernel/entry_64.S | 52 ++---
1 file changed, 26 insertions(+), 26 deletions(-)
--- 3.16-rc2/arch/
>>> On 28.01.14 at 03:18, Mukesh Rathor wrote:
> Until now, xen did not expose PSE to pvh guest, but a patch was submitted
> to xen list to enable bunch of features for a pvh guest. PSE has not been
> looked into for PVH, so until we can do that and test it to make sure it
> works, disable the fea
>>> On 28.01.14 at 18:43, Roger Pau Monne wrote:
> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -985,17 +985,31 @@ static void __end_block_io_op(struct pending_req
> *pending_req, int error)
>* the proper response on the ring.
>*/
>
>>> On 03.02.14 at 17:58, Roger Pau Monné wrote:
> On 29/01/14 09:52, Jan Beulich wrote:
>>>>> On 28.01.14 at 18:43, Roger Pau Monne wrote:
>>> + free_req(blkif, pending_req);
>>> + /*
>>> +*
>>> On 04.02.14 at 09:16, Roger Pau Monné wrote:
> On 04/02/14 09:02, Jan Beulich wrote:
>>>>> On 03.02.14 at 17:58, Roger Pau Monné wrote:
>>> On 29/01/14 09:52, Jan Beulich wrote:
>>>>>>> On 28.01.14 at 18:43, Roger Pau
>>> On 10.12.13 at 06:09, John Stultz wrote:
> static cycle_t logarithmic_accumulation(struct timekeeper *tk, cycle_t
> offset,
> - u32 shift)
> + u32 shift, int *action)
With plain int used here, ...
> @@
Even though the omission was found only during code review (originally
in the Xen hypervisor, looking through ACPI v5 flags and their meanings
and uses), we shouldn't be creating a corresponding platform device in
that case.
Signed-off-by: Jan Beulich
---
v2: Emit a log message in this cas
e on Intel CPUs (intel.c's
instance was lacking the sentinel with family being zero), so the
patch bumps that by one,
- c_models' vendor sub-field was unused (and anyway redundant with
the base structure's c_x86_vendor field), so the patch deletes it.
Signed-off-by: Jan Beul
: x86: unify copy_to_user() and add size checking to it
Signed-off-by: Jan Beulich
Cc: Arjan van de Ven
include/asm/uaccess.h| 98 +++
include/asm/uaccess_32.h | 29 -
include/asm/uaccess_64.h | 28 -
lib/usercopy_32.c
oing forward. I would question
however that commit 2fb0815c9ee6b9ac50e15dd8360ec76d9fa46a2 ("gcc4:
disable __compiletime_object_size for GCC 4.6+") was really necessary,
and instead this should have been dealt with as is done here from the
beginning.
Cc: Arjan van de Ven
Cc: Guenter Roeck
Signed-off-by
Similarly to copy_from_user(), where the range check is to protect
against kernel memory corruption, copy_to_user() can benefit from such
checking too: Here it protects against kernel information leaks.
Signed-off-by: Jan Beulich
Cc: Arjan van de Ven
---
arch/x86/include/asm/uaccess.h
>>> On 21.10.13 at 14:57, Daniel Kiper wrote:
(Looking at the Cc list it's quite interesting that you copied a
whole lot of people, but not me as the maintainer of the EFI
bits in Xen.)
> Separate multiboot2efi module should be established. It should verify system
> kernel and all loaded modules
>>> On 21.10.13 at 16:23, Konrad Rzeszutek Wilk wrote:
> On Mon, Oct 21, 2013 at 02:36:38PM +0100, Jan Beulich wrote:
>> >>> On 21.10.13 at 14:57, Daniel Kiper wrote:
>>
>> (Looking at the Cc list it's quite interesting that you copied a
>> wh
>>> On 21.10.13 at 20:39, Daniel Kiper wrote:
> On Mon, Oct 21, 2013 at 02:36:38PM +0100, Jan Beulich wrote:
>> >>> On 21.10.13 at 14:57, Daniel Kiper wrote:
>> > Separate multiboot2efi module should be established. It should verify
>> > system
>
>>> On 21.10.13 at 20:46, Daniel Kiper wrote:
> On Mon, Oct 21, 2013 at 03:37:21PM +0100, Jan Beulich wrote:
>> >>> On 21.10.13 at 16:23, Konrad Rzeszutek Wilk
>> >>> wrote:
>> > However my understanding is that the general distro approach is
>>> On 22.10.13 at 11:26, Ian Campbell wrote:
> AIUI "efilinux" is somewhat badly named and does not use the Linux Boot
> Protocol (i.e. the (b)zImage stuff with real mode entry point) either.
> It actually loads and executes the kernel binary as a PE/COFF executable
> (the native UEFI binary exec
>>> On 22.10.13 at 11:45, Ian Campbell wrote:
> On Tue, 2013-10-22 at 10:31 +0100, Jan Beulich wrote:
>> >>> On 22.10.13 at 11:26, Ian Campbell wrote:
>> > AIUI "efilinux" is somewhat badly named and does not use the Linux Boot
>> > Protoc
>>> On 22.10.13 at 15:53, Ian Campbell wrote:
> On Tue, 2013-10-22 at 09:42 -0400, Konrad Rzeszutek Wilk wrote:
>
>> Looking at the Fedora GRUB2 source, the 'struct linux_kernel_header' is
> defined
>> in the linux/Documentation/x86/boot.txt and hpa is pretty strict
>> about making it backwards
>>> On 22.10.13 at 16:51, Konrad Rzeszutek Wilk wrote:
> And I still haven't found the module that can launch any PE/COFF
> image from GRUB2. Maybe that is a myth.
I can't exclude that this is a custom a patch as the linuxefi support.
Jan
--
To unsubscribe from this list: send the line "unsubsc
>>> Ian Campbell 10/23/13 10:32 AM >>>
>The second (standard PE/COFF entry point) can be launched using the UEFI
>chainloader call. AIUI this should work with xen.efi today. There are
>some limitations however, firstly there is no way to pass additional
>blobs and so the launched image must load e
>>> Konrad Rzeszutek Wilk 10/23/13 3:15 PM >>>
>On Wed, Oct 23, 2013 at 09:32:30AM +0100, Ian Campbell wrote:
>> Am I correct that xen.efi today can be loaded from grub today using the
>> chainload command? Whereupon it will parse the xen.cfg and load the dom0
>> kernel and load things from FAT et
>>> Vladimir 'φ-coder/phcoder' Serbinenko 10/23/13 7:02 PM
>>> >>>
>> GrUB - which iiuc stays in memory
>> after transferring control - could export its file system support to its
>> descendants).
>
>Xen shouldn't need to load any file after multiboot2 entry point. The
>needed files would already
>>> On 17.12.13 at 23:34, "Luck, Tony" wrote:
>> No, it hasn't. But I explicitly checked the relevant EFI=n and EFI=y
>> cases.
>
> I pushed your patch into my "next" tree - the robots will notice soon and
> send us e-mail if they find any issues.
Thanks, Tony. I'm afraid though that fixing th
>>> On 21.08.14 at 11:30, wrote:
> On 08/20/2014 09:26 PM, Toshi Kani wrote:
>> On Tue, 2014-08-19 at 15:25 +0200, jgr...@suse.com wrote:
>>> --- a/arch/x86/mm/init.c
>>> +++ b/arch/x86/mm/init.c
>>> @@ -27,6 +27,35 @@
>>>
>>> #include "mm_internal.h"
>>>
>>> +/*
>>> + * Tables translating betwe
>>> On 19.08.14 at 15:25, wrote:
> @@ -118,8 +167,14 @@ void pat_init(void)
> PAT(4, WB) | PAT(5, WC) | PAT(6, UC_MINUS) | PAT(7, UC);
>
> /* Boot CPU check */
> - if (!boot_pat_state)
> + if (!boot_pat_state) {
> rdmsrl(MSR_IA32_CR_PAT, boot_pat_state);
>
>>> On 27.08.14 at 09:30, wrote:
> I'm curious about the difference. :-)
>
> sync_set_bit() is only used in drivers/hv/ and drivers/xen/ while set_bit()
> is used in all other places. What makes hv/xen special?
I guess this would really want to be used by anything communicating
with a hyperviso
>>> On 28.08.14 at 16:08, wrote:
> The Xen change that broke Linux PVH guests must be reverted. This
> change may also have broken other guests (e.g., Mirage or one of the
> other unikernel OSes).
If PVH wasn't tech preview, I'd agree. But since it is, I don't see a
reason to revert that change.
>>> One Thousand Gnomes 08/20/14 2:08 PM >>>
>> The Linux kernel currently supports only 4 different cache modes. The PAT MSR
>> is set up in a way that the setting of _PAGE_PAT in a pte doesn't matter: the
>> top 4 entries in the PAT MSR are the same as the 4 lower entries.
>>
>> This results in
>>> On 04.09.14 at 14:38, <"jgr...@suse.com".non-mime.internet> wrote:
> As the KEXEC and DUMPCORE related ELFNOTES are not relevant for the
> kernel they are omitted from elfnote.h.
But the defines are still in the patch:
> @@ -153,6 +192,65 @@
> */
> #define XEN_ELFNOTE_SUPPORTED_FEATURES 17
>>> On 04.09.14 at 14:52, wrote:
> On 04/09/14 13:38, Juergen Gross wrote:
>> --- a/arch/x86/xen/xen-head.S
>> +++ b/arch/x86/xen/xen-head.S
>> @@ -124,6 +124,9 @@ NEXT_HYPERCALL(arch_6)
>> ELFNOTE(Xen, XEN_ELFNOTE_L1_MFN_VALID,
>> .quad _PAGE_PRESENT; .quad _PAGE_PRESENT)
>>
>>> On 04.09.14 at 15:02, wrote:
> On 04/09/14 13:59, David Vrabel wrote:
>> On 04/09/14 13:38, Juergen Gross wrote:
>>> Direct Xen to place the initial P->M table outside of the initial
>>> mapping, as otherwise the 1G (implementation) / 2G (theoretical)
>>> restriction on the size of the initial
>>> On 29.08.14 at 16:27, wrote:
> Sure. Btw, someone also contacted me saying they have the same problem
> without
> changing the layout but having really big initrd (500M). While that feels
> like
> it should be impossible (if the kernel+initrd+xen stuff has to fix the 512M
> kernel image size
use rdi here?
>>
>> I changed this entire area in v2: basically, I will not change the logic,
>> but will add comments explaining what are we doing here, and why.
>> (Some minor code changes will be done, not affecting the logic).
>>
>> While we are at it, what
>>> On 11.08.14 at 11:07, wrote:
> How does one test the entry CFI annotations? The best that I know of
> is to single-step through using gdb attached to qemu and see whether
> backtraces seem to work.
Or have the kernel generate a backtrace from a suitable location and
check that the backtrace
>>> On 11.08.14 at 15:26, wrote:
> On 08/11/2014 10:40 AM, Jan Beulich wrote:
>>>>>> CFI_ESCAPE 0x0f /* DW_CFA_def_cfa_expression */, 6, \
>>>>>> 0x77 /* DW_OP_breg7 */, 0, \
>>>>>>
>>> On 11.08.14 at 16:53, wrote:
> On 08/11/2014 07:17 AM, Jan Beulich wrote:
>>>
>>> The existing comments explain what every byte means.
>>> They are useful if CFI-literate reader wants to check correctness
>>> of the encoding of this annotatio
>>> On 12.08.14 at 11:31, wrote:
> Jan, Pater, does this look correct _and_ human-understandable?
>
> --- a/arch/x86/kernel/entry_64.S
> +++ b/arch/x86/kernel/entry_64.S
> @@ -652,10 +652,14 @@ END(interrupt)
> cmovzq PER_CPU_VAR(irq_stack_ptr),%rsp
> CFI_DEF_CFA_REGISTERrsi
>
>>> "H. Peter Anvin" 11/04/14 9:11 PM >>>
>On 11/04/2014 11:45 AM, tip-bot for Jan Beulich wrote:
>> x86-64: Use RIP-relative addressing for most per-CPU accesses
>>
>> Observing that per-CPU data (in the SMP case) is reachable by
>> exploi
>>> Andy Lutomirski 11/04/14 8:33 PM >>>
>On 11/04/2014 12:49 AM, Jan Beulich wrote:
>> Observing that per-CPU data (in the SMP case) is reachable by
>> exploiting 64-bit address wraparound, these two patches
>> arrange for using the one byte shorter R
>>> Andy Lutomirski 11/04/14 8:40 PM >>>
>On 11/04/2014 01:24 AM, Jan Beulich wrote:
>> The main obstacle to having done this long ago was the need to
>> determine whether annotations are needed in the first place: They need
>> to be avoided when a frame
>>> On 05.11.14 at 18:23, wrote:
> On Wed, Nov 5, 2014 at 9:13 AM, Jan Beulich wrote:
>>>>> Andy Lutomirski 11/04/14 8:40 PM >>>
>>>On 11/04/2014 01:24 AM, Jan Beulich wrote:
>>>> The main obstacle to having done this long ago was the nee
allows the driver to be loaded again with
it being able to create the VFs anew, but which also allows to then
pass through the PF instead of the VFs).
Don't do this however for any VFs currently in active use by a guest.
Signed-off-by: Jan Beulich
---
drivers/xen/xen-pciback/pci_stub.c |
>>> On 28.10.14 at 12:18, wrote:
> Commit-ID: a425cf83e39f99a70168c184e79cea8c67ba7c12
> Gitweb:
> http://git.kernel.org/tip/a425cf83e39f99a70168c184e79cea8c67ba7c12
> Author: Jan Beulich
> AuthorDate: Tue, 16 Sep 2014 13:44:24 +0100
> Committer: Ingo Mo
>>> On 29.10.14 at 08:50, wrote:
> * Jan Beulich wrote:
>
>> >>> On 28.10.14 at 12:18, wrote:
>> > Commit-ID: a425cf83e39f99a70168c184e79cea8c67ba7c12
>> > Gitweb:
> http://git.kernel.org/tip/a425cf83e39f99a70168c184e79cea8c67ba7c12
stubbing it out when !CONFIG_X86_IO_APIC was at least
questionable.
Signed-off-by: Jan Beulich
Cc: Jiang Liu
---
Note: This replaces (rather than fixes) the previously sent "ix86: fix
build failure when !CONFIG_X86_IO_APIC" (which conflicts with the
commit mentioned above).
---
arch/x8
padding
bytes each of the final four sets have) this doesn't seem to provide
any real benefit: Both irq_entries_start and common_interrupt getting
cache line aligned, eliminating the 30th set would just produce 32
bytes of padding between the 29th and common_interrupt.
Signed-off-by: Jan Be
Jan,
having run into that warning too, I looked into it a little, and now
having found that patch am pretty uncertain: Both truncate_setsize()
and pagecache_isize_extended() document that they want to be
called with i_mutex held, so removing the WARN_ON() alone seems
either incomplete or wrong. Wh
>>> On 03.11.14 at 23:18, wrote:
> On Mon, Nov 03, 2014 at 04:41:13PM +, Jan Beulich wrote:
>> having run into that warning too, I looked into it a little, and now
>> having found that patch am pretty uncertain: Both truncate_setsize()
>> and pagecache_isize_exte
preceding it (which was slightly wrong from at least
from 2.6.37 onwards).
The code bloat was observed in reality with an experimental x86 patch
I'm about to post as RFC.
Signed-off-by: Jan Beulich
---
include/linux/irqflags.h |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- 3.1
t got converted to per-CPU data years ago).
Signed-off-by: Jan Beulich
---
arch/x86/include/asm/percpu.h|2 +-
arch/x86/include/asm/processor.h |4 ++--
arch/x86/kernel/setup_percpu.c |2 +-
arch/x86/kernel/smpboot.c|2 +-
4 files changed, 5 insertions(+), 5 dele
This is in preparation of using RIP-relative addressing in many of the
per-CPU accesses.
Signed-off-by: Jan Beulich
---
arch/x86/boot/compressed/misc.c | 14 +-
arch/x86/tools/relocs.c | 38 --
2 files changed, 41 insertions(+), 11
addressing for most per-CPU accesses
Signed-off-by: Jan Beulich
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FA
he dependency on the minimum kernel load address, arbitrarily
low values for CONFIG_PHYSICAL_START are now no longer possible. A
link time assertion is being added, directing to the need to increase
that value when it triggers.
Signed-off-by: Jan Beulich
---
a
s)
arch/x86/kernel/kprobes/
arch/x86/kernel/kvm/
drivers/char/i8k.c:i8k_smm()
drivers/char/toshiba.c:tosh_smm()
drivers/lguest/x86/
Signed-off-by: Jan Beulich
Cc: Tony Jones
---
arch/x86/Makefile| 22
arch/x86/include/as
>>> On 22.07.15 at 00:29, wrote:
> On Mon, 2015-07-20 at 08:46 +0100, Jan Beulich wrote:
>> Make WT really mean WT (rather than UC).
>>
>> I can't see why commit 9cd25aac1f ("x86/mm/pat: Emulate PAT when it is
>> disabled") didn't make th
>>> On 22.07.15 at 17:23, wrote:
> On Wed, 2015-07-22 at 09:17 -0600, Jan Beulich wrote:
>> >
>> > > > On 22.07.15 at 00:29, wrote:
>> > On Mon, 2015-07-20 at 08:46 +0100, Jan Beulich wrote:
>> > > Make WT really mean WT (rather than UC
>>> On 22.07.15 at 18:06, wrote:
> On Wed, 2015-07-22 at 09:41 -0600, Jan Beulich wrote:
>> >
>> > > > On 22.07.15 at 17:23, wrote:
>> > On Wed, 2015-07-22 at 09:17 -0600, Jan Beulich wrote:
>> > > >
>> > > > > &
>>> On 22.07.15 at 20:06, wrote:
> Add comments to the cachemode translation tables to clarify that
> the default values are set as minimal supported mode, which are
> necessary to handle WC and WT fallback to UC- when they are not
> enabled.
Wait - shouldn't WT fall back to UC (so to not be affe
>>> On 22.07.15 at 21:23, wrote:
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -1015,6 +1015,7 @@ config VM86
> config X86_16BIT
> bool "Enable support for 16-bit segments" if EXPERT
> default y
> + depends on MODIFY_LDT_SYSCALL
> ---help---
> This option is
>>> On 23.07.15 at 16:27, wrote:
> On Thu, 2015-07-23 at 00:42 -0600, Jan Beulich wrote:
>> >
>> > > > On 22.07.15 at 20:06, wrote:
>> > Add comments to the cachemode translation tables to clarify that
>> > the default values are set as mini
>>> On 23.07.15 at 17:25, wrote:
> Yes, I agree with you. But such risk is very low -- 1) the regular case
> (no fallback) is used most of the cases, 2) the code using WT knows what
> type of memory it is dealing with. For example, pmem may map NVDIMM with
> WT, and any sane BIOS sets MTRR to WB
ld this be any better than the current, "special awful" stubs?
>Thing 2: vdso compilation with binutils that doesn't support .cfi directives
>
>Userspace debuggers really like having the vdso properly
>CFI-annotated, and the 32-bit fast syscall entries are annotatied
>m
>>> Heinrich Schuchardt 05/08/16 8:13 AM >>>
>--- a/drivers/xen/gntdev.c
>+++ b/drivers/xen/gntdev.c
>@@ -915,36 +915,43 @@ static int gntdev_grant_copy_seg(struct
>gntdev_copy_batch *batch,
>static long gntdev_ioctl_grant_copy(struct gntdev_priv *priv, void __user *u)
>{
>struct ioctl_gntdev_gra
boot a HVM guest with 64 or more
vCPU-s, which was reported by Konrad Rzeszutek Wilk
.
Signed-off-by: Jan Beulich
---
drivers/xen/evtchn.c | 22 ++
1 file changed, 6 insertions(+), 16 deletions(-)
--- 4.6-rc6/drivers/xen/evtchn.c
+++ 4.6-rc6-xen-dev-evtchn-resize/drivers
>>> On 04.05.16 at 17:34, wrote:
> On 04/05/16 14:30, David Vrabel wrote:
>> On 04/05/16 14:02, Jan Beulich wrote:
>>> The copying of ring data was wrong for two cases: For a full ring
>>> nothing got copied at all (as in that case the canonicalized producer
&g
>>> Boris Ostrovsky 05/25/16 9:17 PM >>>
>On 05/05/2016 12:58 AM, Lv Zheng wrote:
>> +static u8
>> +acpi_hw_get_access_bit_width(struct acpi_generic_address *reg, u8
>> max_bit_width)
>> +{
>> +u64 address;
>> +
>> +if (!reg->access_width) {
>> +/*
>> + * Detect old regist
The switch to elf_getshdr{num,strndx} post-dates the oldest tool chain
the kernel is supposed to be able to build with, so try to cope with
such an environment.
Signed-off-by: Jan Beulich
---
tools/objtool/Makefile|4
tools/objtool/elf.h |5 +
2 files changed
number of files getting such warnings by about 99% for me.
Signed-off-by: Jan Beulich
---
tools/objtool/builtin-check.c | 37 -
1 file changed, 36 insertions(+), 1 deletion(-)
--- 4.6-rc7/tools/objtool/builtin-check.c
+++ 4.6-rc7-objtool-BUG-older-gcc/tools/
>>> On 15.12.15 at 15:36, wrote:
> On 12/14/2015 10:27 AM, Konrad Rzeszutek Wilk wrote:
>> On Sat, Dec 12, 2015 at 07:25:55PM -0500, Boris Ostrovsky wrote:
>>> Using MMUEXT_TLB_FLUSH_MULTI doesn't buy us much since the hypervisor
>>> will likely perform same IPIs as would have the guest.
>>>
>> Bu
>>> On 15.12.15 at 16:14, wrote:
> On 12/15/2015 10:03 AM, Jan Beulich wrote:
>>>>> On 15.12.15 at 15:36, wrote:
>>> On 12/14/2015 10:27 AM, Konrad Rzeszutek Wilk wrote:
>>>> On Sat, Dec 12, 2015 at 07:25:55PM -0500, Boris Ostrovsky wrote:
>&g
>>> On 15.12.15 at 16:37, wrote:
> On 12/15/2015 10:24 AM, Jan Beulich wrote:
>>>>> On 15.12.15 at 16:14, wrote:
>>> On 12/15/2015 10:03 AM, Jan Beulich wrote:
>>>>>>> On 15.12.15 at 15:36, wrote:
>>>>> On 12/14/2015 10:
>>> On 10.09.15 at 13:37, wrote:
> On Thu, 10 Sep 2015, Mark Rutland wrote:
>> Why can't Xen give a virtual EFI interface to Dom0 / guests? e.g.
>> create pages of RuntimeServicesCode that are trivial assembly shims
>> doing hypercalls, and plumb these into the virtual EFI memory map and
>> tables
>>> On 10.09.15 at 14:58, wrote:
> On Thu, 2015-09-10 at 13:15 +0100, Mark Rutland wrote:
>
>> > In any case this should be separate from the shim ABI discussion.
>>
>> I disagree; I think this is very much relevant to the ABI discussion.
>> That's not to say that I insist on a particular approa
>>> On 10.09.15 at 16:53, wrote:
> On Thu, Sep 10, 2015 at 01:55:25PM +0100, Jan Beulich wrote:
>> >>> On 10.09.15 at 13:37, wrote:
>> > On Thu, 10 Sep 2015, Mark Rutland wrote:
>> >> Why can't Xen give a virtual EFI interface to Dom0 / guests
>>> On 14.09.15 at 11:36, wrote:
> On 14 September 2015 at 11:31, Shannon Zhao wrote:
>> My understanding is that if there are no EFI_MEMORY_RUNTIME regions, it
>> means we can't use runtime services and should not set the bit
>> EFI_RUNTIME_SERVICES of efi.flags. But if efi_virtmap_init() return
>>> On 14.09.15 at 13:16, wrote:
> (I still think not using SetVirtualAddressMap() at all
> would be the best approach for arm64, but unfortunately, most of my
> colleagues disagree with me)
Any reasons they have? I'm curious because we run x86 Xen without
using this function ...
Jan
--
To unsu
>>> On 24.11.15 at 13:57, wrote:
> V Tue, 24 Nov 2015 10:35:03 +
> Andrew Cooper napsáno:
>
>> On 24/11/15 10:17, Petr Tesarik wrote:
>> > On Tue, 24 Nov 2015 10:09:01 +
>> > David Vrabel wrote:
>> >
>> >> On 24/11/15 09:55
>>> On 24.11.15 at 14:46, wrote:
> On Tue, 2015-11-24 at 10:35 +, Andrew Cooper wrote:
>> On 24/11/15 10:17, Petr Tesarik wrote:
>> > On Tue, 24 Nov 2015 10:09:01 +
>> > David Vrabel wrote:
>> >
>> > > On 24/11/15 09:55, Malcol
>>> On 09.12.15 at 15:32, wrote:
> --- a/arch/x86/kernel/rtc.c
> +++ b/arch/x86/kernel/rtc.c
> @@ -200,6 +200,9 @@ static __init int add_rtc_cmos(void)
> }
> #endif
>
> + if (paravirt_enabled())
> + return -ENODEV;
What about Xen Dom0?
Jan
--
To unsubscribe from this li
>>> On 09.12.15 at 16:15, wrote:
> On 12/09/2015 10:00 AM, Sander Eikelenboom wrote:
>> On 2015-12-09 15:42, Jan Beulich wrote:
>>>>>> On 09.12.15 at 15:32, wrote:
>>>> --- a/arch/x86/kernel/rtc.c
>>>> +++ b/arch/x86/kernel/rtc.c
Make WT really mean WT (rather than UC).
I can't see why commit 9cd25aac1f ("x86/mm/pat: Emulate PAT when it is
disabled") didn't make this match its changes to pat_init().
Signed-off-by: Jan Beulich
Cc: Borislav Petkov
Cc: Toshi Kani
---
arch/x86/mm/init.c |6 +++--
Complete the set of dependent features that need disabling at once:
XSAVEC, AVX-512 and all currently known to the kernel extensions to it,
as well as MPX need to be disabled too.
Signed-off-by: Jan Beulich
---
arch/x86/kernel/fpu/init.c |6 ++
1 file changed, 6 insertions(+)
--- 4.2
pages. The cases when __change_page_attr() calls
__cpa_process_fault(), otoh, don't generally mean the entire range got
processed (as can be seen from one of the two success return paths in
__cpa_process_fault() already adjusting ->numpages).
Signed-off-by: Jan Beulich
---
v3: Mostly
t; Provide a get_required_mask op that uses the maximum MFN to calculate
> the DMA mask.
>
> Signed-off-by: David Vrabel
Reviewed-by: Jan Beulich
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
>>> On 12.11.14 at 16:25, wrote:
> +u64
> +xen_swiotlb_get_required_mask(struct device *dev)
> +{
> + u64 max_mfn;
> +
> + max_mfn = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL);
> +
> + return DMA_BIT_MASK(fls64(max_mfn << PAGE_SHIFT) + 1);
> +}
The value the hypercall returns
>>> On 12.11.14 at 17:59, wrote:
> On 12/11/14 15:55, Jan Beulich wrote:
>>>>> On 12.11.14 at 16:25, wrote:
>>> +u64
>>> +xen_swiotlb_get_required_mask(struct device *dev)
>>> +{
>>> + u64 max_mfn;
>>>
>>> On 12.11.14 at 21:36, wrote:
> On Mon, Nov 10, 2014 at 11:42 PM, Jan Beulich wrote:
>>
>> Nothing crashes with the unwind information being wrong. It is
>> solely you who was claiming (without proof) years ago that the
>> unwinder repeatedly caused issues
>>> On 12.11.14 at 16:55, wrote:
On 12.11.14 at 16:25, wrote:
>> +u64
>> +xen_swiotlb_get_required_mask(struct device *dev)
>> +{
>> +u64 max_mfn;
>> +
>> +max_mfn = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL);
>> +
>> +return DMA_BIT_MASK(fls64(max_mfn << PAGE_SHIFT) + 1
901 - 1000 of 1374 matches
Mail list logo
