>>> 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
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
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
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
>>> 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
>>> 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
Commit-ID: a425cf83e39f99a70168c184e79cea8c67ba7c12
Gitweb: http://git.kernel.org/tip/a425cf83e39f99a70168c184e79cea8c67ba7c12
Author: Jan Beulich
AuthorDate: Tue, 16 Sep 2014 13:44:24 +0100
Committer: Ingo Molnar
CommitDate: Tue, 28 Oct 2014 12:01:09 +0100
ix86: Fix build failure
Commit-ID: de8bf1a32bd379a4f953c3146b82c8a438d7aa5d
Gitweb: http://git.kernel.org/tip/de8bf1a32bd379a4f953c3146b82c8a438d7aa5d
Author: Jan Beulich
AuthorDate: Tue, 16 Sep 2014 13:44:24 +0100
Committer: Ingo Molnar
CommitDate: Tue, 28 Oct 2014 11:06:16 +0100
ix86: Fix build failure
Commit-ID: f74954f01ec9bb2004bcc24f247d1f26f1063ad2
Gitweb: http://git.kernel.org/tip/f74954f01ec9bb2004bcc24f247d1f26f1063ad2
Author: Jan Beulich
AuthorDate: Wed, 24 Sep 2014 08:41:30 +0100
Committer: Thomas Gleixner
CommitDate: Wed, 8 Oct 2014 12:31:45 +0200
x86: Unwind-annotate
Commit-ID: 3f63572187f5ae6a0a9e5ebee88b57e6f71c3cd4
Gitweb: http://git.kernel.org/tip/3f63572187f5ae6a0a9e5ebee88b57e6f71c3cd4
Author: Jan Beulich
AuthorDate: Wed, 24 Sep 2014 08:37:00 +0100
Committer: Thomas Gleixner
CommitDate: Wed, 8 Oct 2014 10:05:49 +0200
x86: Improve
Commit-ID: 82ef36449d311a29b20f82fdce0de856057fa691
Gitweb: http://git.kernel.org/tip/82ef36449d311a29b20f82fdce0de856057fa691
Author: Jan Beulich
AuthorDate: Wed, 24 Sep 2014 08:41:30 +0100
Committer: Thomas Gleixner
CommitDate: Wed, 8 Oct 2014 10:05:50 +0200
x86: Unwind-annotate
Commit-ID: 5f1d919a8ca15f450c749227bc5e2e18f3cbfdb4
Gitweb: http://git.kernel.org/tip/5f1d919a8ca15f450c749227bc5e2e18f3cbfdb4
Author: Jan Beulich
AuthorDate: Wed, 24 Sep 2014 08:40:14 +0100
Committer: Thomas Gleixner
CommitDate: Wed, 8 Oct 2014 10:05:49 +0200
x86: Improve
>>> On 29.09.14 at 06:32, wrote:
> On 09/26/2014 06:38 PM, Chen Gang wrote:
>> When failure occurs, after xenbus_dev_error(), need go to fail to let
>> upper caller know about it.
>>
>> Signed-off-by: Chen Gang
>> ---
>> drivers/xen/xen-scsiback.c | 4 +++-
>> 1 file changed, 3 insertions(+),
Signed-off-by: Jan Beulich
---
arch/x86/lib/thunk_32.S | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
--- 3.17-rc6/arch/x86/lib/thunk_32.S
+++ 3.17-rc6-ix86-annotate-thunks/arch/x86/lib/thunk_32.S
@@ -6,22 +6,31 @@
*/
#include
#include
- don't include unneeded headers
- drop redundant entry point label
- complete unwind annotations
- use .L prefix on local labels to not clutter the symbol table
Signed-off-by: Jan Beulich
---
arch/x86/lib/cmpxchg8b_emu.S | 20 +---
1 file changed, 9 insertions(+
- don't include unneeded headers
- don't open-code PER_CPU_VAR()
- drop redundant entry point label
- complete unwind annotations
- use .L prefix on local label to not clutter the symbol table
Signed-off-by: Jan Beulich
---
arch/x86/lib/cmpxchg16b_em
>>> On 17.09.14 at 16:07, wrote:
> On 17/09/14 05:12, Juergen Gross wrote:
>> +static void __init xen_cleanmfnmap(unsigned long vaddr)
>> +{
>> +unsigned long va = vaddr & PMD_MASK;
>> +unsigned long pa;
>> +pgd_t *pgd = pgd_offset_k(va);
>> +pud_t *pud_page = pud_offset(pgd, 0);
>
/pci/irq.c:1259: error: implicit declaration of function
‘mp_should_keep_irq’
make[3]: *** [arch/x86/pci/irq.o] Error 1
Move them to better places.
Signed-off-by: Jan Beulich
Cc: Jiang Liu
---
arch/x86/include/asm/io_apic.h |2 --
arch/x86/include/asm/pci_x86.h |2 ++
arch/x86/k
Andy
following e6577a7ce9 ("x86, vdso: Move the vvar area before the
vdso text") gcc 4.3.4 tells me
.../arch/x86/vdso/vdso2c.c: In function ‘main’:
.../arch/x86/vdso/vdso2c.h:118: warning: assuming signed overflow does not
occur when assuming that (X + c) < X is
always false
.../arch/x86/vdso/vd
>>> 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 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 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 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
>>> 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.
>>> 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 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 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
>>> 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 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
>
>>> 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 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 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
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 31.07.14 at 15:16, wrote:
> Add a RESTRICT ioctl to /dev/xen/privcmd, which allows privileged commands
> file descriptor to be restricted to only working with a particular domain.
The "with" here has been quite confusing, and I realized that you
mean the subject domain rather than the acto
>>> On 04.07.14 at 15:01, wrote:
>>>> 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
> >
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
>>> 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
>>> 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
Commit-ID: 3bab13b015a255b4b812c02670384d7d99a9ca34
Gitweb: http://git.kernel.org/tip/3bab13b015a255b4b812c02670384d7d99a9ca34
Author: Jan Beulich
AuthorDate: Wed, 25 Jun 2014 14:11:22 +0100
Committer: Ingo Molnar
CommitDate: Wed, 16 Jul 2014 15:23:06 +0200
x86/debug: Drop several
Commit-ID: d093601be5e97d2729614419d0d256ed3b6a56b0
Gitweb: http://git.kernel.org/tip/d093601be5e97d2729614419d0d256ed3b6a56b0
Author: Jan Beulich
AuthorDate: Thu, 3 Jul 2014 15:35:07 +0100
Committer: H. Peter Anvin
CommitDate: Thu, 10 Jul 2014 16:06:04 -0700
x86-32, vdso: Fix vDSO
Commit-ID: 9f88b906b4455465d60ac18b8c95904f320038d5
Gitweb: http://git.kernel.org/tip/9f88b906b4455465d60ac18b8c95904f320038d5
Author: Jan Beulich
AuthorDate: Thu, 3 Jul 2014 15:34:38 +0100
Committer: H. Peter Anvin
CommitDate: Thu, 10 Jul 2014 15:59:56 -0700
x86-64, vdso: Fix vDSO
>>> 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 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 done
> in lz4_decompress() with regards to potential pointer overflows.
Except that meanwhile Don agre
>>> On 03.07.14 at 17:34, wrote:
> On Thu, Jul 3, 2014 at 7: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 th
align_vdso_addr() causes the build to fail.
Signed-off-by: Jan Beulich
Cc: Andy Lutomirski
---
arch/x86/vdso/vma.c|4
1 file changed, 4 insertions(+)
--- 3.16-rc3/arch/x86/vdso/vma.c
+++ 3.16-rc3-x86-vdso-build/arch/x86/vdso/vma.c
@@ -62,6 +62,9 @@ struct linux_binprm;
Only
Certain ld versions (observed with 2.20.0) put an empty .rela.dyn
section into shared object files, breaking the assumption on the number
of sections to be copied to the final output. Simply discard any empty
SHT_REL and SHT_RELA sections to address this.
Signed-off-by: Jan Beulich
Cc: Andy
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 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?
>>> 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 18.06.14 at 15:52, wrote:
> EFI_PARAVIRT will be usable by architectures other than x86, correct? If
> your intention is for it only ever to be used by x86, then it should
> probably be EFI_ARCH_2.
I would expect ARM, once it gets UEFI support on the Xen side, to
be able to handle most of
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 |
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 ++
>>> "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
>>> "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
>>> On 20.05.14 at 13:29, wrote:
> On Tue, May 20, 2014 at 10:47:00AM +0100, David Vrabel wrote:
>> On 16/05/14 21:41, Daniel Kiper wrote:
>> > @@ -1714,6 +1725,21 @@ asmlinkage __visible void __init
>> > xen_start_kernel(void)
>> >
>> >xen_setup_runstate_info(0);
>> >
>> > + efi_systab_xen
>>> On 19.05.14 at 22:46, wrote:
> On Mon, May 19, 2014 at 02:30:45PM +0100, Jan Beulich wrote:
>> >>> On 16.05.14 at 22:41, wrote:
>> > @@ -457,6 +460,21 @@ void __init efi_free_boot_services(void)
>> >efi_unmap_memmap();
>> > }
&g
1999-2002 Hewlett-Packard Co.
>> + * David Mosberger-Tang
>> + * Stephane Eranian
>> + * Copyright (C) 2005-2008 Intel Co.
>> + * Fenghua Yu
>> + * Bibo Mao
>> + * Chandramouli Narayanan
>> + * Huang Ying
>> + * Copyright (C) 2011 Novell C
>>> On 16.05.14 at 22:41, wrote:
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -240,4 +240,7 @@ config XEN_MCE_LOG
> config XEN_HAVE_PVMMU
> bool
>
> +config XEN_EFI
> + def_bool X86_64 && EFI
Constructs like this are bogus - they needlessly add a line to .config
whe
>>> On 16.05.14 at 22:41, wrote:
> @@ -457,6 +460,21 @@ void __init efi_free_boot_services(void)
> efi_unmap_memmap();
> }
>
> +static void __init __iomem *efi_early_ioremap(resource_size_t phys_addr,
> + unsigned long size)
> +{
> +
>>> On 30.04.14 at 15:54, wrote:
> When the device is de-assigned from a guest (but still owned
> by xen-pciback) we would needlessly free all of its dynamic
> entries.
I wonder whether that isn't intentional - dynamic fields are only
being used for what comes through the "quirks" attribute.
> -
>>> On 28.04.14 at 22:50, wrote:
>>> > There's a enable_pci_io_ecs() which enables ECS through the NB_CFG MSR
>>> > which is called as part of the notifier *and* there's a PCI write to
>>> > that same bit in pci_enable_pci_io_ecs() which iterates over all NBs.
>>> >
>>> > So, AFAICT, we do it twic
>>> On 22.04.14 at 20:34, wrote:
> With this patch:
> [...]
> And with an HVM guest poking at the rest of VCPUOPs: VCPUOP_get_physid,
> VCPUOP_initialise, and VCPUOP_send_nmi - either before the CPU is up or
> when it is up - work.
>
> That is: the VCPUOP_get_physid would return -EINVAL; VCPUOP_
>>> On 12.04.14 at 07:56, wrote:
> --- a/arch/x86/kernel/i8259.c
> +++ b/arch/x86/kernel/i8259.c
> @@ -299,11 +299,30 @@ static void unmask_8259A(void)
> static void init_8259A(int auto_eoi)
> {
> unsigned long flags;
> + unsigned char probe_val = ~(1 << PIC_CASCADE_IR);
> + unsign
>>> On 09.04.14 at 17:38, wrote:
> On 04/09/2014 11:01 AM, Jan Beulich wrote:
>>>>> On 09.04.14 at 16:41, wrote:
>>> The latter load however can easy fault; The arguments for %ds in
>>> XSA-42/ CVE-2013-0228 applies to %{e,f,g}s as well.
>> And
>>> On 09.04.14 at 17:27, wrote:
> On Wed, Apr 09, 2014 at 10:06:12AM +0100, Jan Beulich wrote:
>> >>> On 08.04.14 at 19:25, wrote:
>> > --- a/xen/arch/x86/hvm/hvm.c
>> > +++ b/xen/arch/x86/hvm/hvm.c
>> > @@ -3470,6 +3470,9 @@ static long hv
>>> On 09.04.14 at 16:41, wrote:
> The latter load however can easy fault; The arguments for %ds in
> XSA-42/ CVE-2013-0228 applies to %{e,f,g}s as well.
And it was only that latter operation that I pointed at.
> Furthermore, I am a little concerned about the performance impact of
> this. I wo
>>> On 09.04.14 at 16:06, wrote:
> --- a/arch/x86/xen/xen-asm_32.S
> +++ b/arch/x86/xen/xen-asm_32.S
> @@ -88,7 +88,11 @@ ENTRY(xen_iret)
>* avoid having to reload %fs
>*/
> #ifdef CONFIG_SMP
> + pushw %fs
> + movl $(__KERNEL_PERCPU), %eax
> + movl %eax, %fs
> GE
>>> On 09.04.14 at 12:15, wrote:
> On Apr 9, 2014 4:03 AM, Jan Beulich wrote:
>>
>> >>> On 08.04.14 at 19:25, wrote:
>> > + /* Only Xen 4.5 and higher supports this. */
>> > + if (HYPERVISOR_vcpu_op(VCPUOP_is_up, smp_processor_id(), NULL)
>>> On 08.04.14 at 19:25, wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -3470,6 +3470,9 @@ static long hvm_vcpu_op(
> case VCPUOP_stop_singleshot_timer:
> case VCPUOP_register_vcpu_info:
> case VCPUOP_register_vcpu_time_memory_area:
> +case VCPUOP_dow
>>> On 08.04.14 at 19:25, wrote:
> + /* Only Xen 4.5 and higher supports this. */
> + if (HYPERVISOR_vcpu_op(VCPUOP_is_up, smp_processor_id(), NULL) ==
> -ENOSYS)
> + vcpuops = false;
Did you mean to say "for HVM guests" in the comment? And of
course the comment could quickly
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
> 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,
>
>>> On 26.03.14 at 15:58, wrote:
>> +struct xenpf_efi_runtime_call {
>> +uint32_t function;
>> +/*
>> + * This field is generally used for per sub-function flags (defined
>> + * below), except for the XEN_EFI_get_next_high_monotonic_count case,
>> + * where it holds the single
>>> On 26.03.14 at 15:08, wrote:
> On Wed, Mar 26, 2014 at 01:21:19PM +, Jan Beulich wrote:
>> >>> On 25.03.14 at 21:57, wrote:
>> > Export arch_tables variable. Xen init function calls efi_config_init()
>> > which takes it as an argument.
&g
>>> On 26.03.14 at 14:31, wrote:
> On Wed, 26 Mar, at 01:22:49PM, Jan Beulich wrote:
>> >>> On 26.03.14 at 14:00, wrote:
>> >
>> > This could do with a little bit more explanation. Why is it not
>> > necessary to mark the EFI memory map that
>>> On 26.03.14 at 14:12, wrote:
> On Tue, 25 Mar, at 09:57:56PM, Daniel Kiper wrote:
>> +static void __init efi_init_xen(void)
>> +{
>> +efi_char16_t vendor_c16[100];
>> +char vendor[ARRAY_SIZE(vendor_c16)];
>> +int ret, i;
>> +struct xen_platform_op op;
>> +union xenpf_efi_in
>>> On 25.03.14 at 21:57, wrote:
> Define EFI related stuff for Xen.
>
> This patch is based on Jan Beulich and Tang Liang work.
And with this, ...
> Signed-off-by: Daniel Kiper
> Signed-off-by: Tang Liang
> Signed-off-by: Jan Beulich
... these should be in t
>>> On 26.03.14 at 14:00, wrote:
> On Tue, 25 Mar, at 09:57:54PM, Daniel Kiper wrote:
>> Call efi_memblock_x86_reserve_range() on native EFI platform only.
>> This is not needed and even it should not be called on platforms
>> which wraps EFI infrastructure like Xen.
>>
>> Signed-off-by: Daniel K
>>> On 25.03.14 at 21:57, wrote:
> Export arch_tables variable. Xen init function calls efi_config_init()
> which takes it as an argument.
>
> Additionally, put __initdata in place suggested by include/linux/init.h.
Which isn't necessarily the most appropriate place.
> --- a/arch/x86/platform/e
Commit-ID: 06325190bd577e11429444d54f454b9d13f560c9
Gitweb: http://git.kernel.org/tip/06325190bd577e11429444d54f454b9d13f560c9
Author: Jan Beulich
AuthorDate: Thu, 27 Feb 2014 08:47:02 +
Committer: H. Peter Anvin
CommitDate: Wed, 19 Mar 2014 16:51:04 -0700
x86, hash: Fix build
Commit-ID: 7a5917e9787dd73284f04e35c3cfdb39a67bf0d5
Gitweb: http://git.kernel.org/tip/7a5917e9787dd73284f04e35c3cfdb39a67bf0d5
Author: Jan Beulich
AuthorDate: Thu, 27 Feb 2014 08:47:58 +
Committer: H. Peter Anvin
CommitDate: Wed, 19 Mar 2014 16:51:04 -0700
x86, hash: Simplify
Commit-ID: c5cdfdf90901c51363441365997eecd58efd9374
Gitweb: http://git.kernel.org/tip/c5cdfdf90901c51363441365997eecd58efd9374
Author: Jan Beulich
AuthorDate: Thu, 27 Feb 2014 08:47:34 +
Committer: H. Peter Anvin
CommitDate: Wed, 19 Mar 2014 16:51:04 -0700
x86, hash: Swap
Commit-ID: bbe831de1924f56596848919f98b195ed250fd28
Gitweb: http://git.kernel.org/tip/bbe831de1924f56596848919f98b195ed250fd28
Author: Jan Beulich
AuthorDate: Thu, 27 Feb 2014 08:47:34 +
Committer: H. Peter Anvin
CommitDate: Wed, 19 Mar 2014 16:26:14 -0700
x86, hash: Swap
Commit-ID: 706b158559e41ba8d8ea83f3e468466e64769058
Gitweb: http://git.kernel.org/tip/706b158559e41ba8d8ea83f3e468466e64769058
Author: Jan Beulich
AuthorDate: Thu, 27 Feb 2014 08:47:02 +
Committer: H. Peter Anvin
CommitDate: Wed, 19 Mar 2014 16:25:03 -0700
x86, hash: Fix build
Commit-ID: d31abcbca0e076f2a136d214f409b55bf149fade
Gitweb: http://git.kernel.org/tip/d31abcbca0e076f2a136d214f409b55bf149fade
Author: Jan Beulich
AuthorDate: Thu, 27 Feb 2014 08:47:58 +
Committer: H. Peter Anvin
CommitDate: Wed, 19 Mar 2014 16:26:44 -0700
x86, hash: Simplify
>>> On 17.03.14 at 17:55, "H. Peter Anvin" wrote:
> On 03/17/2014 05:19 AM, George Dunlap wrote:
>> On Mon, Mar 17, 2014 at 3:33 AM, H. Peter Anvin wrote:
>>> No, the right thing is to unf*ck the Xen braindamage and use eagerfpu as a
> workaround for the legacy hypervisor versions.
>>
>> The in
- simplify switch statement
- add __init annotation to setup_arch_fast_hash()
Signed-off-by: Jan Beulich
Cc: Francesco Fusco
Cc: Daniel Borkmann
Cc: Thomas Graf
Cc: David S. Miller
---
arch/x86/lib/hash.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
--- 3.14-rc4-x86
... to match the function's parameters. While reportedly commutative,
using the proper order allows for leveraging the instruction permitting
the source operand to be in memory.
Signed-off-by: Jan Beulich
Acked-by: Daniel Borkmann
Cc: Francesco Fusco
Cc: Thomas Graf
Cc: David S. M
Just like for other ISA extension instruction uses we should check
whether the assembler actually supports them. The fallback here simply
is to encode an instruction with fixed operands (%eax and %ecx).
Signed-off-by: Jan Beulich
Cc: Francesco Fusco
Cc: Daniel Borkmann
Cc: Thomas Graf
Cc
1: fix build failure with older binutils
2: x86/hash: swap arguments passed to crc32_u32()
3: cleanup
Signed-off-by: Jan Beulich
Cc: Francesco Fusco
Cc: Daniel Borkmann
Cc: Thomas Graf
Cc: David S. Miller
---
v2: 2nd patch now swaps arguments rather than parameters, as
requested by hpa
>>> On 25.02.14 at 21:37, "H. Peter Anvin" wrote:
> On 02/25/2014 12:34 PM, Daniel Borkmann wrote:
>> On 02/25/2014 09:26 PM, H. Peter Anvin wrote:
>>> On 02/21/2014 02:33 AM, Jan Beulich wrote:
>>>> ... to match its two callers (i.e. the alternat
>>> On 24.02.14 at 14:01, "H. Peter Anvin" wrote:
> I never expected that the CRC32 operation would be commutative. Very
> fascinating.
Neither did I, which is why I was very surprised for Daniel to say that
things worked with the apparently wrong order.
Jan
--
To unsubscribe from this list:
>>> On 24.02.14 at 13:32, "H. Peter Anvin" wrote:
> On 02/24/2014 03:46 AM, Daniel Borkmann wrote:
>>>
>>> --- 3.14-rc3-x86-hash-crc32.orig/arch/x86/lib/hash.c
>>> +++ 3.14-rc3-x86-hash-crc32/arch/x86/lib/hash.c
>>> @@ -37,7 +37,7 @@
>>> #include
>>> #include
>>> On 24.02.14 at 12:46, Daniel Borkmann wrote:
> On 02/24/2014 11:53 AM, Jan Beulich wrote:
>>>>> On 24.02.14 at 11:22, Daniel Borkmann wrote:
>>> On 02/24/2014 09:03 AM, Jan Beulich wrote:
>>>>>>> On 22.02.14 at 13:09, Daniel Borkman
>>> On 24.02.14 at 11:22, Daniel Borkmann wrote:
> On 02/24/2014 09:03 AM, Jan Beulich wrote:
>>>>> On 22.02.14 at 13:09, Daniel Borkmann wrote:
>>> On 02/21/2014 11:33 AM, Jan Beulich wrote:
>>>> ... to match its two callers (i.e. the alternati
>>> On 22.02.14 at 13:09, Daniel Borkmann wrote:
> On 02/21/2014 11:33 AM, Jan Beulich wrote:
>> ... to match its two callers (i.e. the alternative would have been to
>> swap the arguments at the call sites).
>>
>> Signed-off-by: Jan Beulich
>> Cc: Fran
>>> On 21.02.14 at 20:17, "H. Peter Anvin" wrote:
> On 02/21/2014 06:16 AM, Jan Beulich wrote:
>>>>> On 21.02.14 at 13:51, "H. Peter Anvin" wrote:
>>> How old?
>>
>> 2.16.91.0.5 (SLE10)
>>
>
> I would *love* to
>>> On 21.02.14 at 13:51, "H. Peter Anvin" wrote:
> How old?
2.16.91.0.5 (SLE10)
Jan
> On February 21, 2014 2:32:50 AM PST, Jan Beulich wrote:
>>Just like for other ISA extension instruction uses we should check
>>whether the assembler actually supports t
- simplify switch statement
- add __init annotation to setup_arch_fast_hash()
Signed-off-by: Jan Beulich
Cc: Francesco Fusco
Cc: Daniel Borkmann
Cc: Thomas Graf
Cc: David S. Miller
---
arch/x86/lib/hash.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
--- 3.14-rc3-x86
Just like for other ISA extension instruction uses we should check
whether the assembler actually supports them. The fallback here simply
is to encode an instruction with fixed operands (%eax and %ecx).
Signed-off-by: Jan Beulich
Cc: Francesco Fusco
Cc: Daniel Borkmann
Cc: Thomas Graf
Cc
501 - 600 of 1372 matches
Mail list logo
