Re: [linus:master] [x86/entry] be5341eb0d: WARNING:CPU:#PID:#at_int80_emulation

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

Re: [linus:master] [x86/entry] be5341eb0d: WARNING:CPU:#PID:#at_int80_emulation

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's not

Re: [linus:master] [x86/entry] be5341eb0d: WARNING:CPU:#PID:#at_int80_emulation

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.

Re: [linus:master] [x86/entry] be5341eb0d: WARNING:CPU:#PID:#at_int80_emulation

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) >

Re: [PATCH v2 0/8] x86/mtrr: fix handling with PAT but without MTRR

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

Re: [GIT PULL] xen: branch for v5.17-rc3

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

Re: [GIT PULL] xen: branch for v5.17-rc3

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

Re: [PATCH v2 0/6] memblock: cleanup memblock_free interface

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

Re: [PATCH 0/3] memblock: cleanup memblock_free interface

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()'

Re: Linux 5.13-rc6 regression to 5.12.x: kernel OOM and panic during kernel boot in low memory Xen VM's (256MB assigned memory).

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 >

Re: Linux 5.11-rc6 compile error

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

Re: [GIT PULL] xen: branch for v5.9-rc4

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

Re: [Xen-devel] [GIT PULL] dma-mapping updates for 5.4

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

Re: [Xen-devel] [PATCH] x86: make set_pmd_at() paravirt aware

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

Re: [Xen-devel] Linux 5.0 regression: BUG: unable to handle kernel paging request at ffff888023e26778

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

Re: [Xen-devel] remove the ->mapping_error method from dma_map_ops V3

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

Re: [Xen-devel] remove the ->mapping_error method from dma_map_ops V2

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

Re: [Xen-devel] remove the ->mapping_error method from dma_map_ops V2

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 >

Re: [Xen-devel] remove the ->mapping_error method from dma_map_ops V2

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

Re: [Xen-devel] remove the ->mapping_error method from dma_map_ops V2

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

Re: [Xen-devel] remove the ->mapping_error method from dma_map_ops V2

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

Re: [Xen-devel] remove the ->mapping_error method from dma_map_ops V2

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

Re: [Xen-devel] remove the ->mapping_error method from dma_map_ops V2

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()

Re: [Xen-devel] remove the ->mapping_error method from dma_map_ops V2

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

Re: [Xen-devel] [GIT PULL] xen: fixes for 4.20-rc1

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

Re: [Xen-devel] [GIT PULL] (xen-swiotlb) stable/for-linus-4.20

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 >

Re: [Xen-devel] [GIT PULL] xen: fixes for 4.16 rc1

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

Re: [Xen-devel] [GIT PULL] xen: fixes for 4.16 rc1

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