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, 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 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 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 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 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 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 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 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 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 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 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, 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 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 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, 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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
31 matches
Mail list logo
