This should be accompanied by
addr2 = __START_KERNEL_map + __pa(address);
/* Make sure the kernel mappings stay executable */
prot2 = pte_pgprot(pte_mkexec(pfn_pte(0, prot)));
- err = __change_page_attr(a
>Please discuss.
I don't think there's much to discuss - Yoichi Yuasa's changes can be simply
brought through to the other patch (of which I continue to only state that X
has a problem, the patch fixes it for me [and perhaps *only* me], and afaik
X itself still hasn't been fixed in this respect).
>>> On 11.12.14 at 00:34, wrote:
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -4239,6 +4239,16 @@ int __sched _cond_resched(void)
> }
> EXPORT_SYMBOL(_cond_resched);
>
> +int __sched cond_resched_irq(void)
> +{
> + if (should_resched()) {
> + preempt_schedule_ir
>>> David Vrabel 12/23/14 12:01 PM >>>
>On 19/12/14 16:16, Jan Beulich wrote:
>> Using the native code here can't work properly, as the hypervisor would
>> normally have cleared the two reason bits by the time Dom0 gets to see
>> the NMI (if passed to
de -> IST exception -> NMI, then
>task_pt_regs is entirely uninitialized. Assuming all the CFI
>annotations are correct, the unwinder could still do it from the
>kernel.
>
>Note that, as far as I know, Jan Beulich is the only person who uses
>the unwinder on kernel code. Jan
>>> Andy Lutomirski 01/02/15 7:03 PM >>>
>On Jan 2, 2015 8:11 AM, "Jan Beulich" wrote:
>> Trying to guess what you mean by "this": A stack switch gets expressed by
>> CFI annotations just like any other frame pointer adjustments. See f
>>> David Vrabel 01/05/15 11:35 AM >>>
>On 19/12/14 16:16, Jan Beulich wrote:
>> Using the native code here can't work properly, as the hypervisor would
>> normally have cleared the two reason bits by the time Dom0 gets to see
>> the NMI (if passed to
>>> On 04.12.14 at 12:07, wrote:
> On 03/12/14 21:40, Konrad Rzeszutek Wilk wrote:
>> From: Jan Beulich
>>
>> When a PF driver unloads, it may find it necessary to leave the VFs
>> around simply because of pciback having marked them as assigned to a
>>
There not being a similar difference in page fault handling, I can't
see why 32- and 64-bit should differ in behavior here.
Signed-off-by: Jan Beulich
---
arch/x86/kernel/traps.c |2 --
1 file changed, 2 deletions(-)
--- 3.19-rc5/arch/x86/kernel/traps.c
+++ 3.19-rc5-ix86-show-unha
by exiting the
outer loop when max_faults is still zero after the inner loop. For the
compiler's sake, mark max_group uninitialized, as we're now able to
prove it's not actually being used uninitalized anymore.
Signed-off-by: Jan Beulich
Cc: Rik van Riel
---
kernel/sched/fair.c |
Just like for AVX2 (which simply needs an #if -> #ifdef conversion),
SSSE3 assembler support should be checked for before using it.
Signed-off-by: Jan Beulich
Cc: Jim Kukunas
Cc: Neil Brown
---
arch/x86/Makefile |1 +
lib/raid6/algos.c |2 +-
lib/raid6/recov_avx2.c |
The compiler validly warns about it being ignored.
Signed-off-by: Jan Beulich
---
arch/x86/kernel/cpu/mcheck/mce_amd.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- 3.19-rc5/arch/x86/kernel/cpu/mcheck/mce_amd.c
+++ 3.19-rc5-x86-MCE-AMD-bank4_names/arch/x86/kernel/cpu/mcheck
Not just setting it when the feature is available is for consistency,
and may allow Xen to drop its custom clearing of the flag (unless it
needs it cleared earlier than this code executes). Note that the change
is benign to ix86, as the flag starts out clear there.
Signed-off-by: Jan Beulich
As a module_init() function, this should have been this way from the
beginning.
Signed-off-by: Jan Beulich
---
drivers/xen/tmem.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- 3.19-rc5/drivers/xen/tmem.c
+++ 3.19-rc5-xen-tmem-init/drivers/xen/tmem.c
@@ -374,7 +374,7 @@ static
>>> On 23.01.15 at 10:54, wrote:
> On Fri, Jan 23, 2015 at 08:25:38AM +, Jan Beulich wrote:
>> At least some gcc versions - validly afaict - warn about potentially
>> using max_group uninitialized: There's no way the compiler can prove
>> that the b
>>> On 23.01.15 at 10:58, wrote:
> On Fri, Jan 23, 2015 at 08:32:01AM +, Jan Beulich wrote:
>> The compiler validly warns about it being ignored.
>>
>> Signed-off-by: Jan Beulich
>
> Applied, thanks.
>
> Out of curiosity: When do you see thi
>>> On 23.01.15 at 19:58, wrote:
> On Fri, Jan 23, 2015 at 11:45:06AM +, David Vrabel wrote:
>> On 23/01/15 00:29, Luis R. Rodriguez wrote:
>> > @@ -1243,6 +1247,25 @@ void xen_evtchn_do_upcall(struct pt_regs *regs)
>> >set_irq_regs(old_regs);
>> > }
>> >
>> > +/*
>> > + * CONFIG_PREEMP
>>> On 13.01.15 at 14:29, wrote:
> Em Tue, Jan 13, 2015 at 08:48:35AM +, Jan Beulich escreveu:
>> Arnaldo,
>>
>> considering that tools/include/ gets used by other than just perf, in
>> particular arch/x86/vdso/vdso2c.c, would you mind clarifying how
>
>>> On 07.01.15 at 17:30, wrote:
> On Wed, 2015-01-07 at 17:16 +0100, Imre Palik wrote:
>> From: "Palik, Imre"
>>
>> In Dom0's the use of the TSC clocksource (whenever it is stable enough to
>> be used) instead of the Xen clocksource should not cause any issues, as
>> Dom0 VMs never live-migrate
>>> On 08.01.15 at 18:01, wrote:
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -140,7 +140,7 @@ static void __init xen_del_extra_mem(u64 start, u64 size)
> unsigned long __ref xen_chk_extra_mem(unsigned long pfn)
> {
> int i;
> - unsigned long addr = PFN_PHYS(pfn);
> +
>>> On 09.01.15 at 13:51, wrote:
> On 09/01/15 09:57, Jan Beulich wrote:
>>>>> On 08.01.15 at 18:01, wrote:
>>> @@ -284,7 +286,7 @@ static void __init xen_update_mem_tables(unsigned long
>>> pfn, unsigned long mfn)
>>> }
>&
t hold zero all the time. Note
further that hardware NMI handling for PVH doesn't currently work
anyway due to missing code in the hypervisor (but it is expected to
work the native rather than the PV way).
Signed-off-by: Jan Beulich
Reviewed-by: Boris Ostrovsky
---
v2: Use DEFINE_GUEST_HANDLE
Arnaldo,
considering that tools/include/ gets used by other than just perf, in
particular arch/x86/vdso/vdso2c.c, would you mind clarifying how
"tools: Move bitops.h from tools/perf/util to tools/" adding an
inclusion of asm/hweight.h to linux/bitops.h is supposed to work,
when the only potentiall
The mis-naming likely was a copy-and-paste effect.
Signed-off-by: Jan Beulich
---
arch/x86/kernel/irq.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- 3.19-rc4/arch/x86/kernel/irq.c
+++ 3.19-rc4-xen-x86-HYP-interrupt/arch/x86/kernel/irq.c
@@ -127,7 +127,7 @@ int
>>> On 27.01.15 at 02:51, wrote:
Even if David told you this would be acceptable, I have to question
an abstract model of fixing issues on only 64-bit kernels - this may
be acceptable for distro purposes, but seems hardly the right
approach for upstream. If 32-bit ones are to become deliberately
>>> On 28.01.15 at 15:29, wrote:
> Commit-ID: 81907478c4311a679849216abf723999184ab984
> Gitweb:
> http://git.kernel.org/tip/81907478c4311a679849216abf723999184ab984
> Author: Jan Beulich
> AuthorDate: Fri, 23 Jan 2015 08:25:38 +
> Committer: Ingo Mo
Linus,
while the description of commit cae2a173fe certainly makes sense, the
change itself ignores the __probe_kernel_write() code path, for which
the destination address is expected to be in kernel space but accesses
may still fault. I.e. the use of plain memset() causes
__probe_kernel_write() to
>>> On 23.04.15 at 17:33, wrote:
> On Tue, Apr 21, 2015 at 11:33 PM, Jan Beulich wrote:
>>
>> while the description of commit cae2a173fe certainly makes sense, the
>> change itself ignores the __probe_kernel_write() code path, for which
>> the destination
>>> On 23.04.15 at 17:33, wrote:
> On Tue, Apr 21, 2015 at 11:33 PM, Jan Beulich wrote:
>>
>> while the description of commit cae2a173fe certainly makes sense, the
>> change itself ignores the __probe_kernel_write() code path, for which
>> the destination
>>> On 10.04.15 at 16:37, wrote:
> On 03/04/15 15:28, Konrad Rzeszutek Wilk wrote:
>> Hey David and Boris,
>>
>> Please see the two patches - the first one fixes an situation that
>> the original XSA-120 patch hadn't considered.
>>
>> The second patch is more of just a cleanup. Can be 4.1 materi
>>> On 20.04.15 at 19:09, wrote:
> A different approach, given the dual nature of the AC flag now is to gate
> setup_smap() on a kernel rpl of 0. SMAP necessarily can't be used in a
> paravirtual situation where the kernel runs in cpl > 0.
"Can't" isn't true here - for 64-bit PV Xen guests, whic
>>> On 11.04.15 at 01:05, wrote:
>> One might argue that this code serves no purpose, but it's there, so
>> we had better keep our per-invocation usage of DEBUG_STACK within 4k.
>
> Only if you run NKLD. I doubt KDB or GDB support nesting.
> We can ask Jan if he still uses it.
I didn't have the
While commit efa7045103 ("x86/asm/entry: Make user_mode() work
correctly if regs came from VM86 mode") claims that "user_mode() is now
identical to user_mode_vm()", this wasn't actually the case - no prior
commit made it so.
Signed-off-by: Jan Beulich
Cc: Andy Lutomirs
y make DEFAULT_FRAME capable of expressing both.
Signed-off-by: Jan Beulich
Cc: Denys Vlasenko
Cc: Andy Lutomirski
---
arch/x86/kernel/entry_64.S | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
--- 4.1-rc5/arch/x86/kernel/entry_64.S
+++ 4.1-rc5-x86_64-unwind-info/arch
... when the checked expression is compile time constant.
Signed-off-by: Jan Beulich
---
drivers/xen/tmem.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- 4.1-rc5/drivers/xen/tmem.c
+++ 4.1-rc5-tmem-BUILD_BUG_ON/drivers/xen/tmem.c
@@ -395,7 +395,7 @@ static int __init
Older compilers don't recognize that "v" can't be used uninitialized;
other code using hvm_get_parameter() zeros the value too, so follow
suit here.
Signed-off-by: Jan Beulich
---
drivers/xen/xenbus/xenbus_probe.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
Older compilers don't recognize that "v" can't be used uninitialized;
other code using hvm_get_parameter() zeros the value too, so follow
suit here.
Signed-off-by: Jan Beulich
---
drivers/tty/hvc/hvc_xen.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
... as their only caller is.
Signed-off-by: Jan Beulich
---
arch/x86/mm/ioremap.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- 4.1-rc5/arch/x86/mm/ioremap.c
+++ 4.1-rc5-x86-ioremap-huge-supported/arch/x86/mm/ioremap.c
@@ -331,7 +331,7 @@ void iounmap(volatile void __iomem
>>> On 28.05.15 at 11:01, wrote:
> * Jan Beulich wrote:
>> --- 4.1-rc5/arch/x86/kernel/entry_64.S
>> +++ 4.1-rc5-x86_64-unwind-info/arch/x86/kernel/entry_64.S
>> @@ -148,7 +148,7 @@ ENDPROC(native_usergs_sysret64)
>> /*
>> * frame that enables
>>> On 28.05.15 at 12:36, wrote:
> On 28/05/15 09:23, Jan Beulich wrote:
>> ... when the checked expression is compile time constant.
>
> Commit messages should be complete sentences, please.
Do you mean I should repeat the start of the sentence from the
title
>>> On 28.05.15 at 13:20, wrote:
> * Jan Beulich wrote:
>> Not sure why assembly code should look like C code. It's a matter of taste
>> perhaps, and I can see your point, but I'm also not really eager to do
> changes
>> just to match other people&#
Signed-off-by: Jan Beulich
---
drivers/xen/tmem.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
---
v2: Drop the description at David's request.
--- 4.1-rc5/drivers/xen/tmem.c
+++ 4.1-rc5-tmem-BUILD_BUG_ON/drivers/xen/tmem.c
@@ -395,7 +395,7 @@ static int __init xen_tmem_init
>>> On 12.06.15 at 01:23, wrote:
> There are two usages on MTRRs:
> 1) MTRR entries set by firmware
> 2) MTRR entries set by OS drivers
>
> We can obsolete 2), but we have no control over 1). As UEFI firmwares
> also set this up, this usage will continue to stay. So, we should not
> get rid o
>>> On 13.06.15 at 01:15, wrote:
> On Jun 12, 2015 12:59 AM, "Jan Beulich" wrote:
>>
>> >>> On 12.06.15 at 01:23, wrote:
>> > There are two usages on MTRRs:
>> > 1) MTRR entries set by firmware
>> > 2) MTRR entries set by
1: allow use of relations other than (in)equality
2: re-generate *.c_shipped files after previous change
Signed-off-by: Jan Beulich
---
Note that while benign for the first patch, the second patch can only
be applied cleanly on top of "kconfig: don't silently ignore unhandled
character
ex values now works as expected: Other
than int ones (which aren't allowed to have leading zeroes), zeroes
following the 0x prefix made them compare unequal even if their values
were equal.
Signed-off-by: Jan Beulich
---
v3: Split changes to generated files from main patch to a subsequent
o
Signed-off-by: Jan Beulich
---
v3: Split off from main patch.
--- a/scripts/kconfig/zconf.lex.c_shipped
+++ b/scripts/kconfig/zconf.lex.c_shipped
@@ -365,333 +365,354 @@ int zconflineno = 1;
extern char *zconftext;
#define yytext_ptr zconftext
-static yyconst flex_int16_t yy_nxt[][17
>>> On 16.06.15 at 21:10, wrote:
> Append 0x to all %x in order to avoid while reading when there is other
> decimal value in the log.
To save on the space taken by the format strings you should prefer
%#x over 0x%x (like we do in the hypervisor).
Jan
--
To unsubscribe from this list: send the
>>> On 22.06.15 at 15:56, wrote:
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -1951,6 +1951,8 @@ static void blkback_changed(struct xenbus_device *dev,
>
> switch (backend_state) {
> case XenbusStateInitWait:
> + if (dev->state != XenbusS
Doing so allows adjustments by 128 bytes (occurring for
REMOVE_PT_GPREGS_FROM_STACK 8 uses) to be expressed with a single byte
immediate.
Signed-off-by: Jan Beulich
---
arch/x86/include/asm/calling.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- 4.1-rc6/arch/x86/include/asm
retint_kernel doesn't require %rcx to be pointing to thread info
(anymore?), and the code on the two alternative paths is - not really
surprisingly - identical.
Signed-off-by: Jan Beulich
Cc: Andy Lutomirski
---
arch/x86/kernel/entry_64.S | 10 ++
1 file changed, 2 insertions(
>>> On 22.05.18 at 05:54, wrote:
> We are making calls to C code (e.g. xen_prepare_pvh()) which may use
> stack canary (stored in GS segment).
>
> Signed-off-by: Boris Ostrovsky
Reviewed-by: Jan Beulich
>>> On 22.05.18 at 15:45, wrote:
> On Mon, May 21, 2018 at 11:54 PM, Boris Ostrovsky
> wrote:
>> @@ -98,6 +101,12 @@ ENTRY(pvh_start_xen)
>> /* 64-bit entry point. */
>> .code64
>> 1:
>> + /* Set base address in stack canary descriptor. */
>> + mov $MSR_GS_BASE,%ecx
>>> On 22.05.18 at 17:15, wrote:
> On Tue, May 22, 2018 at 9:57 AM, Jan Beulich wrote:
>>>>> On 22.05.18 at 15:45, wrote:
>>> On Mon, May 21, 2018 at 11:54 PM, Boris Ostrovsky
>>> wrote:
>>>> @@ -98,6 +101,12 @@ ENTRY(pvh_start_xen)
&g
>>> On 22.05.18 at 18:20, wrote:
> On 05/22/2018 12:10 PM, Jan Beulich wrote:
>>>>> On 22.05.18 at 17:15, wrote:
>>> On Tue, May 22, 2018 at 9:57 AM, Jan Beulich wrote:
>>>>>>> On 22.05.18 at 15:45, wrote:
>>>>
>>> On 22.05.18 at 19:10, wrote:
> On 05/22/2018 12:32 PM, Jan Beulich wrote:
>>>>> On 22.05.18 at 18:20, wrote:
>>> We are loading virtual address for $canary so we will always have EDX
>>> set to 0x. Isn't that what we want?
>>
>>> On 23.05.18 at 16:30, wrote:
> @@ -98,6 +101,12 @@ ENTRY(pvh_start_xen)
> /* 64-bit entry point. */
> .code64
> 1:
> + /* Set base address in stack canary descriptor. */
> + mov $MSR_GS_BASE,%ecx
> + mov $_pa(canary), %rax
> + xor %rdx, %rdx
Why rax and rdx instea
Juergen Gross 03/01/18 8:29 AM >>>
>On 28/02/18 19:28, Maran Wilson wrote:
>> The start info structure that is defined as part of the x86/HVM direct boot
>> ABI and used for starting Xen PVH guests would be more versatile if it also
>> included a way to pass information about the memory map t
Hello,
I've just stumbled across this commit, and I'm wondering if that's actually
correct (I too have at least one system where such IDs are reported in
MADT): For offline/absent CPUs, the firmware may not know the APIC IDs
at the point MADT is built, so I think it is quite reasonable to put ~0 i
>>> On 27.04.18 at 10:32, wrote:
> At 04/27/2018 03:21 PM, Jan Beulich wrote:
>> I've just stumbled across this commit, and I'm wondering if that's actually
>> correct (I too have at least one system where such IDs are reported in
>> MADT): For offli
>>> On 02.05.18 at 03:56, wrote:
> At 04/27/2018 08:09 PM, Jan Beulich wrote:
>> I'm afraid I don't understand: Limiting the number of disabled CPUs is
>> certainly desirable when those can never be used, but why would you
>> want to do this when they m
>>> On 30.04.18 at 18:23, wrote:
> Latest binutils release (2.29.1) will no longer allow proper computation
> of GDT entries on 32-bits, with warning:
>
> arch/x86/xen/xen-pvh.S: Assembler messages:
> arch/x86/xen/xen-pvh.S:150: Warning: shift count out of range (32 is not
> between 0 and 31)
>
>>> On 30.04.18 at 18:23, wrote:
> Signed-off-by: Boris Ostrovsky
Reviewed-by: Jan Beulich
But to understand why things have been working nevertheless it would
have been nice if the commit message wasn't empty, but instead said
something like "The two happen to be identical on 64-bit."
Jan
>>> On 30.04.18 at 18:23, wrote:
> --- a/arch/x86/xen/xen-pvh.S
> +++ b/arch/x86/xen/xen-pvh.S
> @@ -54,6 +54,9 @@
> * charge of setting up it's own stack, GDT and IDT.
> */
>
> +#define PVH_GDT_ENTRY_CANARY4
> +#define PVH_CANARY_SEL (PVH_GDT_ENTRY_CANARY * 8)
I can only advis
>>> On 30.04.18 at 18:23, wrote:
> And without it we can't use _BOOT_XX macros any longer so define new ones.
Ah, here we go. Perhaps this should be moved earlier in the series?
Assuming you really want to go this route in the first place, taking
Roger's comment into consideration.
Jan
>>> On 01.05.18 at 14:34, wrote:
> On 05/01/2018 04:00 AM, Roger Pau Monné wrote:
>> On Mon, Apr 30, 2018 at 12:23:39PM -0400, Boris Ostrovsky wrote:
>>> And without it we can't use _BOOT_XX macros any longer so define new ones.
>>
>> Not being that familiar with Linux internals I'm not sure I se
>>> On 02.05.18 at 16:57, wrote:
> On 05/02/2018 04:05 AM, Jan Beulich wrote:
>>>>> On 30.04.18 at 18:23, wrote:
>>> Signed-off-by: Boris Ostrovsky
>> Reviewed-by: Jan Beulich
>>
>> But to understand why things have been working neverth
>>> On 02.05.18 at 17:00, wrote:
> On 05/02/2018 04:16 AM, Jan Beulich wrote:
>>>>> On 30.04.18 at 18:23, wrote:
>>> --- a/arch/x86/xen/xen-pvh.S
>>> +++ b/arch/x86/xen/xen-pvh.S
>>> @@ -54,6 +54,9 @@
>>> * charge of sett
>>> On 02.05.18 at 17:06, wrote:
> On 05/02/2018 04:26 AM, Jan Beulich wrote:
>>>>> On 01.05.18 at 14:34, wrote:
>>> On 05/01/2018 04:00 AM, Roger Pau Monné wrote:
>>>> On Mon, Apr 30, 2018 at 12:23:39PM -0400, Boris Ostrovsky wrote:
>>>
>>> On 02.05.18 at 17:08, wrote:
> On 05/02/2018 11:00 AM, Jan Beulich wrote:
>>>>> On 02.05.18 at 16:57, wrote:
>>> On 05/02/2018 04:05 AM, Jan Beulich wrote:
>>>>>>> On 30.04.18 at 18:23, wrote:
>>>>> Signed-off-by: Bor
>>> On 02.05.18 at 17:22, wrote:
> On 05/02/2018 11:01 AM, Jan Beulich wrote:
>>>>> On 02.05.18 at 17:00, wrote:
>>> On 05/02/2018 04:16 AM, Jan Beulich wrote:
>>>>>>> On 30.04.18 at 18:23, wrote:
>>>>> --- a/arch/x
>>> On 02.05.18 at 19:29, wrote:
> On 05/02/2018 11:41 AM, Jan Beulich wrote:
>>>>> On 02.05.18 at 17:22, wrote:
>>> On 05/02/2018 11:01 AM, Jan Beulich wrote:
>>>>>>> On 02.05.18 at 17:00, wrote:
>>>>> On 05/02/
>>> 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. The fixup address for the exception points
> * back to the regular execution flow in .text.
> */
> -#define _REFCOUNT_EXCEPTI
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
;
> xen_irq_lateeoi(irq, XEN_EOI_FLAG_SPURIOUS);
> }
>
Ah yes, what was originally meant really was
if (!(xenvif_handle_tx_interrupt(queue) |
xenvif_handle_rx_interrupt(queue))) {
(also hinted at by the otherwise pointless inner parentheses),
which you simply write in an alternative way.
Reviewed-by: Jan Beulich
Jan
Signed-off-by: Jan Beulich
--- a/arch/x86/mm/dump_pagetables.c
+++ b/arch/x86/mm/dump_pagetables.c
@@ -366,7 +366,7 @@ static void ptdump_walk_pgd_level_core(s
{0, PTRS_PER_PGD * PGD_LEVEL_MULT / 2},
{GUARD_HOLE_END_ADDR, ~0UL},
#else
- {0, ~0UL},
+ {0, __FIXADDR_
On 18.08.2020 14:47, Roger Pau Monné wrote:
> On Tue, Aug 18, 2020 at 02:01:35PM +0200, Marek Marczykowski-Górecki wrote:
>> On Mon, Aug 17, 2020 at 11:00:13AM +0200, Roger Pau Monné wrote:
>>> On Sun, Aug 16, 2020 at 02:19:49AM +0200, Marek Marczykowski-Górecki wrote:
In case of Xen PV dom0,
On 20.01.2021 15:35, Roger Pau Monné wrote:
> On Wed, Jan 20, 2021 at 03:23:30PM +0100, Arthur Borsboom wrote:
>> Hi Roger,
>>
>> I have set up a test environment based on Linux 5.11.0-rc4.
>> The patch did not apply clean, so I copied/pasted the patch manually.
>>
>> Without the patch the call tra
size_t arguments can't compatibly be passed for l-modifier format
specifiers. Use z instead.
Fixes: 8382c668ce4f ("x86/vdso: Add support for exception fixup in vDSO
functions")
Signed-off-by: Jan Beulich
--- a/arch/x86/entry/vdso/vdso2c.h
+++ b/arch/x86/entry/vdso/vdso2c.h
On 06.02.2021 11:49, Juergen Gross wrote:
> The ring buffer for user events is used in the local system only, so
> smp barriers are fine for ensuring consistency.
>
> Reported-by: Andrew Cooper
> Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
Albeit I think "local
On 06.02.2021 11:49, Juergen Gross wrote:
> In evtchn_read() use READ_ONCE() for reading the producer index in
> order to avoid the compiler generating multiple accesses.
>
> Signed-off-by: Juergen Gross
> ---
> drivers/xen/evtchn.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> di
On 08.02.2021 10:44, Andrew Cooper wrote:
> On 06/02/2021 10:49, Juergen Gross wrote:
>> The ring buffer for user events is used in the local system only, so
>> smp barriers are fine for ensuring consistency.
>>
>> Reported-by: Andrew Cooper
>> Signed-off-by: Juergen Gross
>
> These need to be v
On 06.02.2021 11:49, Juergen Gross wrote:
> @@ -1798,6 +1818,29 @@ static void mask_ack_dynirq(struct irq_data *data)
> ack_dynirq(data);
> }
>
> +static void lateeoi_ack_dynirq(struct irq_data *data)
> +{
> + struct irq_info *info = info_for_irq(data->irq);
> + evtchn_port_t evtch
On 08.02.2021 11:23, Andrew Cooper wrote:
> On 08/02/2021 09:50, Jan Beulich wrote:
>> On 08.02.2021 10:44, Andrew Cooper wrote:
>>> On 06/02/2021 10:49, Juergen Gross wrote:
>>>> The ring buffer for user events is used in the local system only, so
>>&
On 08.02.2021 11:41, Jürgen Groß wrote:
> On 08.02.21 10:48, Jan Beulich wrote:
>> On 06.02.2021 11:49, Juergen Gross wrote:
>>> In evtchn_read() use READ_ONCE() for reading the producer index in
>>> order to avoid the compiler generating multiple accesses.
>>&
On 08.02.2021 11:59, Jürgen Groß wrote:
> On 08.02.21 11:51, Jan Beulich wrote:
>> On 08.02.2021 11:41, Jürgen Groß wrote:
>>> On 08.02.21 10:48, Jan Beulich wrote:
>>>> On 06.02.2021 11:49, Juergen Gross wrote:
>>>>> In evtchn_read() use READ_ONCE()
On 08.02.2021 13:15, Jürgen Groß wrote:
> On 08.02.21 12:54, Jan Beulich wrote:
>> On 08.02.2021 11:59, Jürgen Groß wrote:
>>> On 08.02.21 11:51, Jan Beulich wrote:
>>>> On 08.02.2021 11:41, Jürgen Groß wrote:
>>>>> On 08.02.21 10:48, Jan Beulich wro
On 27.01.2021 11:30, Paul Durrant wrote:
> From: Paul Durrant
>
> Prior to commit 4a8c31a1c6f5 ("xen/blkback: rework connect_ring() to avoid
> inconsistent xenstore 'ring-page-order' set by malicious blkfront"), the
> behaviour of xen-blkback when connecting to a frontend was:
>
> - read 'ring-p
On 27.01.2021 11:26, Jürgen Groß wrote:
> On 27.01.21 10:43, Andrew Cooper wrote:
>> On 27/01/2021 09:38, Juergen Gross wrote:
>>> diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
>>> index 4409306364dc..ca5ac10fcbf7 100644
>>> --- a/arch/x86/xen/enlighten_pv.c
>>> +++ b/arch/
On 27.01.2021 12:09, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 27 January 2021 10:57
>> To: Paul Durrant
>> Cc: Paul Durrant ; Konrad Rzeszutek Wilk
>> ; Roger Pau
>> Monné ; Jens Axboe ; Dongli Zhang
>
On 27.01.2021 12:33, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 27 January 2021 11:21
>> To: p...@xen.org
>> Cc: 'Paul Durrant' ; 'Konrad Rzeszutek Wilk'
>> ; 'Roger Pau
>> Monné' ; '
>>> 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 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 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 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 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 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 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
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
701 - 800 of 1374 matches
Mail list logo
