On Wed, Sep 18, 2019 at 8:27 AM Christoph Hellwig wrote:
>
> please pull the dma-mapping updates for 5.4.
Pulled.
> In addition to the usual Kconfig conflics where you just want to keep
> both edits there are a few more interesting merge issues this time:
>
> - most importanly powerpc and micro
On Sat, Feb 9, 2019 at 12:24 AM Sander Eikelenboom wrote:
>
> I haven't got a reproducer so i might be hard to hit it again,
> system is AMD and this is from the host kernel running under
> the Xen hypervisor might it matter.
I think this is a Xen bug.
In particular, there's a few poison values
On Sat, Feb 9, 2019 at 11:41 PM Juergen Gross wrote:
>
> Make set_pmd_at() paravirt aware by just letting it use set_pmd().
Well, that was simpler than I worried.
Just checking: Is this purely an x86 issue? ARM is ok perhaps because
there's no PV support?
Linus
___
On Tue, Nov 27, 2018 at 11:41 PM Christoph Hellwig wrote:
>
> On Fri, Nov 23, 2018 at 07:55:11AM +0100, Christoph Hellwig wrote:
> > Well, I can tweak the last patch to return -EINVAL from dma_mapping_error
> > instead of the old 1 is as bool true. The callers should all be fine,
> > although I'd
On Wed, Nov 28, 2018 at 9:45 AM Russell King - ARM Linux
wrote:
>
> > I don't think this is a huge deal, but ERR_PTR() has been hugely
> > successful elsewhere. And I'm not hugely convinced about all these
> > "any address can be valid" arguments. How the hell do you generate a
> > random dma addr
On Wed, Nov 28, 2018, 10:08 Russell King - ARM Linux >
> > You already cannot do that kmalloc(), exactly because of ERR_PTR().
>
> I'm very sorry, but I think you are confused.
>
> kmalloc() returns a _virtual_ address, which quite rightly must not be
> in the top 4K of 4GB, exactly due to ERR_PTR
On Thu, Nov 29, 2018 at 8:23 AM Christoph Hellwig wrote:
>
> We can. At least in theory. The problem is that depending on the
> crazy mapping from physical and kernel virtual address to dma addresses
> these might be pages at pretty random places. Look at fun like
> arch/x86/pci/sta2x11-fixup.c
On Thu, Nov 29, 2018 at 10:31 AM Christoph Hellwig wrote:
>
> > Or, better yet, plan on removing the single-page dma mappign entirely
> > at a later date, and make the issue moot.
>
> What would be the replacement? Build a S/G list for every single page
> mapping? Not sure that would create a lo
On Fri, Nov 30, 2018 at 5:23 AM Christoph Hellwig wrote:
>
> Error reporting for the dma_map_single and dma_map_page operations is
> currently a mess. [..]
I don't see anything objectionable there, but it's not like I checked
any of the context of the patches. For all I know there are odd corner
On Mon, Oct 22, 2018 at 8:33 PM Konrad Rzeszutek Wilk wrote:
>
> one tiny fix for the Xen SWIOTLB mechanism that occasionally happened with
> devices that didn't allocate size in power of two but rather some odd
> sizes. We neglected to make the memory coherent leading to all kinds of fun
> cra
On Fri, Feb 9, 2018 at 6:28 AM, Juergen Gross wrote:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
> for-linus-4.16-rc1-tag
So I've pulled this, but the back-merges *really* annoy me.
Seriously, DON'T DO MERGES IF YOU CANNOT EVEN BE BOTHERED TO WRITE A
REASON FOR THEM!
There a
On Fri, Feb 9, 2018 at 10:59 AM, Juergen Gross wrote:
>
> Do you want me to setup the patches for pulling again?
No, I've pulled, I just don't want to see these unexplained merges again.
Preferably I don't want to see back-merges at all, but when I do see
them, I want to see an explanation for w
On Tue, Oct 30, 2018 at 12:44 AM Juergen Gross wrote:
>
> It contains only several small fixes and cleanups this time.
Pulled,
Linus
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/li
On Thu, Nov 22, 2018 at 6:03 AM Christoph Hellwig wrote:
>
> The 0 return doesn't work for direct mappings that have ram at address
> zero and a lot of IOMMUs that start allocating bus space from address
> zero, so we can't consolidate on that, but I think we can move everyone
> to all-Fs, which t
On Thu, Nov 22, 2018 at 9:07 AM Russell King - ARM Linux
wrote:
>
> I'm afraid that won't work very well - 32 bit platforms with 64-bit
> addresses (LPAE) would have dma_addr_t as a 64-bit value, which
> wouldn't fit into an unsigned long.
Good point. So we'd have to have a special IS_DMA_ERR() f
On Thu, Nov 22, 2018 at 9:52 AM Robin Murphy wrote:
>
> Unfortunately, with things like the top-down IOVA allocator, and 32-bit
> systems in general, "the top 4095" values may well still be valid
> addresses -
Ugh.
> The only immediate benefit I can see is that we could distinguish cases
> like
On Sat, Sep 5, 2020 at 9:44 PM Juergen Gross wrote:
>
> It contains a small series for fixing a problem with Xen PVH guests
> when running as backends (e.g. as dom0). Mapping other guests' memory
> now is working via ZONE_DEVICE, thus not requiring to abuse the memory
> hotplug functionality for t
On Wed, Feb 3, 2021 at 11:58 AM Shuah Khan wrote:
>
> ld: arch/x86/built-in.a: member arch/x86/kernel/pci-swiotlb.o in archive
> is not an object
> make: *** [Makefile:1170: vmlinux] Error 1
That honestly sounds like something went wrong earlier - things like
doing a system upgrade in the middle
On Wed, 2 Oct 2024 at 08:31, Ard Biesheuvel wrote:
>
> I guess you are referring to the use of a GOT? That is a valid
> concern, but it does not apply here. With hidden visibility and
> compiler command line options like -mdirect-access-extern, all emitted
> symbol references are direct.
I absolu
On Sat, 5 Oct 2024 at 16:37, H. Peter Anvin wrote:
>
> Sadly, that is not correct; neither gcc nor clang uses lea:
Looking around, this may be intentional. At least according to Agner,
several cores do better at "mov immediate" compared to "lea".
Eg a RIP-relative LEA on Zen 2 gets a throughput
On Wed, 25 Sept 2024 at 08:16, Ard Biesheuvel wrote:
>
> Instead of pushing an immediate absolute address, which is incompatible
> with PIE codegen or linking, use a LEA instruction to take the address
> into a register.
I don't think you can do this - it corrupts %rdi.
Yes, the code uses %rdi
On Sat, Feb 5, 2022 at 3:07 AM Juergen Gross wrote:
>
> Please git pull the following tag:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
> for-linus-5.17a-rc3-tag
Diffstat? Shortlog?
This is not a valid pull request.
Linus
On Sat, Feb 5, 2022 at 9:58 AM Linus Torvalds
wrote:
>
> On Sat, Feb 5, 2022 at 3:07 AM Juergen Gross wrote:
> >
> > Please git pull the following tag:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
> > for-linus-5.17a-rc3-tag
>
> D
On Wed, Feb 15, 2023 at 12:25 AM Juergen Gross wrote:
>
> The problem arises in case a large mapping is spanning multiple MTRRs,
> even if they define the same caching type (uniform is set to 0 in this
> case).
Oh, I think then you should fix uniform to be 1.
IOW, we should not think "multiple M
On Thu, Jun 17, 2021 at 2:26 AM Sander Eikelenboom wrote:
>
> I just tried to upgrade and test the linux kernel going from the 5.12 kernel
> series to 5.13-rc6 on my homeserver with Xen, but ran in some trouble.
>
> Some VM's boot fine (with more than 256MB memory assigned), but the smaller
> (m
On Tue, 19 Dec 2023 at 01:58, Borislav Petkov wrote:
>
> Looking at the dmesg, I think you missed the most important part - the
> preceding line:
>
> [ 13.480504][ T48] CFI failure at int80_emulation+0x67/0xb0 (target:
> sys_ni_posix_timers+0x0/0x70; expected type: 0xb02b34d9)
>
On Tue, 19 Dec 2023 at 11:15, Andrew Cooper wrote:
>
> -asmlinkage long sys_ni_posix_timers(void);
> +asmlinkage long sys_ni_posix_timers(const struct pt_regs *regs);
I don't think it should be asmlinkage. That means "use legacy asm
calling conventions", and for x86-32 that means pass on stack. W
On Tue, 19 Dec 2023 at 12:17, Linus Torvalds
wrote:
>
> That said, I still think that just getting rid of this horrid special
> case for posix timers is the right thing, and we should just remove
> that SYS_NI() alias thing entirely.
IOW, something like the attached patch.
It'
On Wed, 20 Dec 2023 at 15:40, Sami Tolvanen wrote:
>
> I tested the patch with the 0-day bot reproducer and it does fix the
> warning. My usual arm64 and riscv configs also seem to build and boot
> just fine.
Thanks. I've been running it on my machine too, and still don't see
anything wrong with
On Thu, Sep 23, 2021 at 12:43 AM Mike Rapoport wrote:
>
> The core change is in the third patch that makes memblock_free() a
> counterpart of memblock_alloc() and adds memblock_phys_alloc() to be a
^^^
> counterpart of memblock_phys_alloc().
That should be 'memblock_phys_free()'
On Thu, Sep 30, 2021 at 11:50 AM Mike Rapoport wrote:
>
> The first patch is a cleanup of numa_distance allocation in arch_numa I've
> spotted during the conversion.
> The second patch is a fix for Xen memory freeing on some of the error
> paths.
Well, at least patch 2 looks like something that s
On Mon, 28 Apr 2025 at 00:14, Ingo Molnar wrote:
>
> And, just out of intellectual curiosity, I also tried to measure the
> code generation price of the +1 standards-quirk in the fls()/ffs()
> interface as well:
>
> ... and unless I messed up the patch, it seems to have a surprisingly
> low impact
On Mon, 28 Apr 2025 at 00:05, Ingo Molnar wrote:
>
> And once we remove 486, I think we can do the optimization below to
> just assume the output doesn't get clobbered by BS*L in the zero-case,
> right?
We probably can't, because who knows what "Pentium" CPU's are out there.
Or even if Pentium r
On Sun, 27 Apr 2025 at 12:17, Andrew Cooper wrote:
>
> ffs/fls are commonly found inside loops where x is the loop condition
> too. Therefore, using statically_true() to provide a form without the
> zero compatibility turns out to be a win.
We already have the version without the zero capability
On Tue, 29 Apr 2025 at 15:22, Andrew Cooper wrote:
>
> Oh, I didn't realise there was also a perf difference too, but Agner Fog
> agrees.
The perf difference is exactly because of the issue where the non-rep
one acts as a cmov, and has basically two inputs (the bits to test in
the source, and the
On Tue, 29 Apr 2025 at 14:24, H. Peter Anvin wrote:
>
> Could you file a gcc bug? Gcc shouldn't generate worse code than inline asm
> ...
Honestly, I've given up on that idea.
That's basically what the bug report I reported about clts was - gcc
generating worse code than inline asm.
But why wo
On Tue, 29 Apr 2025 at 14:59, Andrew Cooper wrote:
>
> do_variable_ffs() doesn't quite work.
>
> REP BSF is LZCNT, and unconditionally writes it's output operand, and
> defeats the attempt to preload with -1.
>
> Drop the REP prefix, and it should work as intended.
Bah. That's what I get for just
On Mon, 28 Apr 2025 at 19:00, H. Peter Anvin wrote:
>
> Now, question: can we just use __builtin_*() for these? I think gcc should
> always generate inline code for these on x86.
Yeah, I think we can just use __builtin_ffs() directly and get rid of
all the games.
Not all gcc builtins are great:
On Sat, 26 Apr 2025 at 12:24, Linus Torvalds
wrote:
>
> (And yes, one use in a x86 header file that is pretty questionable
> too: I think the reason for the cmov is actually i486-only behavior
> and we could probably unify the 32-bit and 64-bit implementation)
Actually, what we *shou
On Sat, 26 Apr 2025 at 11:59, Arnd Bergmann wrote:
>
> Right. With the current set of features, CMOV is almost the
> same as 686. My reasoning was that support for CMOV has a
> very clear definition, with the instruction either being
> available or not.
Yeah, I don't think there's any reason to m
On Tue, 29 Apr 2025 at 07:38, Andrew Cooper wrote:
>
> I tried that. (The thread started as a question around
> __builtin_constant_p() but did grow to cover __builtin_ffs().)
Maybe we could do something like
#define ffs(x) \
(statically_true((x) != 0) ? __ffs(x)+1 : __builtin_ffs(x))
On Tue, 29 Apr 2025 at 12:13, Andrew Cooper wrote:
>
> That would improve code generation for 32bit, but generally regress 64bit.
>
> Preloading the destination register with -1 is better than the CMOV form
> emitted by the builtin; BSF's habit of conditionally not writing the
> destination regist
42 matches
Mail list logo
