Re: [Xen-devel] [PATCH v7 0/7] KVM: x86: Allow Qemu/KVM to use PVH entry point
I wonder why I am starting to get CCed on Xen patches all of a sudden. I happened to run into Jürgen at a conference only last weekend, but I still don't know anything whatsoever about Xen or how it works. If get_maintainer.pl has started to return my name on this stuff I really want to know why :/ Yours, Linus Walleij ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [PATCH v5 09/10] dma-buf-map: Add memcpy and pointer-increment interfaces
Overall I like this, just an inline question:
On Tue, Oct 20, 2020 at 2:20 PM Thomas Zimmermann wrote:
> To do framebuffer updates, one needs memcpy from system memory and a
> pointer-increment function. Add both interfaces with documentation.
(...)
> +/**
> + * dma_buf_map_memcpy_to - Memcpy into dma-buf mapping
> + * @dst: The dma-buf mapping structure
> + * @src: The source buffer
> + * @len: The number of byte in src
> + *
> + * Copies data into a dma-buf mapping. The source buffer is in system
> + * memory. Depending on the buffer's location, the helper picks the correct
> + * method of accessing the memory.
> + */
> +static inline void dma_buf_map_memcpy_to(struct dma_buf_map *dst, const void
> *src, size_t len)
> +{
> + if (dst->is_iomem)
> + memcpy_toio(dst->vaddr_iomem, src, len);
> + else
> + memcpy(dst->vaddr, src, len);
> +}
Are these going to be really big memcpy() operations?
Some platforms have DMA offload engines that can perform memcpy(),
drivers/dma, include/linux/dmaengine.h
especially if the CPU doesn't really need to touch the contents
and flush caches etc.
An example exist in some MTD drivers that move large quantities of
data off flash memory like this:
drivers/mtd/nand/raw/cadence-nand-controller.c
Notice that DMAengine and DMAbuf does not have much in common,
the names can be deceiving.
The value of this varies with the system architecture. It is not just
a question about performance but also about power and the CPU
being able to do other stuff in parallel for large transfers. So *when*
to use this facility to accelerate memcpy() is a delicate question.
What I'm after here is if these can be really big, do we want
(in the long run, not now) open up to the idea to slot in
hardware-accelerated memcpy() here?
Yours,
Linus Walleij
Re: [PATCH 11/11] drm/tiny: drm_gem_simple_display_pipe_prepare_fb is the default
On Fri, May 21, 2021 at 11:10 AM Daniel Vetter wrote: > Goes through all the drivers and deletes the default hook since it's > the default now. > > Signed-off-by: Daniel Vetter > Cc: Joel Stanley > Cc: Andrew Jeffery > Cc: "Noralf Trønnes" > Cc: Linus Walleij > Cc: Emma Anholt > Cc: David Lechner > Cc: Kamlesh Gurudasani > Cc: Oleksandr Andrushchenko > Cc: Daniel Vetter > Cc: Maxime Ripard > Cc: Thomas Zimmermann > Cc: Sam Ravnborg > Cc: Alex Deucher > Cc: Andy Shevchenko > Cc: linux-asp...@lists.ozlabs.org > Cc: linux-arm-ker...@lists.infradead.org > Cc: xen-devel@lists.xenproject.org Acked-by: Linus Walleij Yours, Linus Walleij
[PATCH] x86/xen: Make virt_to_pfn() a static inline
Making virt_to_pfn() a static inline taking a strongly typed
(const void *) makes the contract of a passing a pointer of that
type to the function explicit and exposes any misuse of the
macro virt_to_pfn() acting polymorphic and accepting many types
such as (void *), (unitptr_t) or (unsigned long) as arguments
without warnings.
Also fix all offending call sites to pass a (void *) rather
than an unsigned long. Since virt_to_mfn() is wrapping
virt_to_pfn() this function has become polymorphic as well
so the usage need to be fixed up.
Signed-off-by: Linus Walleij
---
arch/x86/include/asm/xen/page.h | 5 -
arch/x86/xen/enlighten_pv.c | 2 +-
arch/x86/xen/mmu_pv.c | 12 ++--
arch/x86/xen/setup.c| 4 ++--
4 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index fa9ec20783fa..85e63d58c074 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -295,7 +295,10 @@ static inline unsigned long bfn_to_local_pfn(unsigned long
mfn)
/* VIRT <-> MACHINE conversion */
#define virt_to_machine(v) (phys_to_machine(XPADDR(__pa(v
-#define virt_to_pfn(v) (PFN_DOWN(__pa(v)))
+static inline unsigned long virt_to_pfn(const void *v)
+{
+ return PFN_DOWN(__pa(v));
+}
#define virt_to_mfn(v) (pfn_to_mfn(virt_to_pfn(v)))
#define mfn_to_virt(m) (__va(mfn_to_pfn(m) << PAGE_SHIFT))
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index 93b658248d01..7178976c5dcf 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -523,7 +523,7 @@ static void __init xen_load_gdt_boot(const struct desc_ptr
*dtr)
BUG_ON(size > PAGE_SIZE);
BUG_ON(va & ~PAGE_MASK);
- pfn = virt_to_pfn(va);
+ pfn = virt_to_pfn((void *)va);
mfn = pfn_to_mfn(pfn);
pte = pfn_pte(pfn, PAGE_KERNEL_RO);
diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
index e0a975165de7..c4f20581f6e7 100644
--- a/arch/x86/xen/mmu_pv.c
+++ b/arch/x86/xen/mmu_pv.c
@@ -2202,13 +2202,13 @@ static void xen_zap_pfn_range(unsigned long vaddr,
unsigned int order,
mcs = __xen_mc_entry(0);
if (in_frames)
- in_frames[i] = virt_to_mfn(vaddr);
+ in_frames[i] = virt_to_mfn((void *)vaddr);
MULTI_update_va_mapping(mcs.mc, vaddr, VOID_PTE, 0);
- __set_phys_to_machine(virt_to_pfn(vaddr), INVALID_P2M_ENTRY);
+ __set_phys_to_machine(virt_to_pfn((void *)vaddr),
INVALID_P2M_ENTRY);
if (out_frames)
- out_frames[i] = virt_to_pfn(vaddr);
+ out_frames[i] = virt_to_pfn((void *)vaddr);
}
xen_mc_issue(0);
}
@@ -2250,7 +2250,7 @@ static void xen_remap_exchanged_ptes(unsigned long vaddr,
int order,
MULTI_update_va_mapping(mcs.mc, vaddr,
mfn_pte(mfn, PAGE_KERNEL), flags);
- set_phys_to_machine(virt_to_pfn(vaddr), mfn);
+ set_phys_to_machine(virt_to_pfn((void *)vaddr), mfn);
}
xen_mc_issue(0);
@@ -2327,7 +2327,7 @@ int xen_create_contiguous_region(phys_addr_t pstart,
unsigned int order,
xen_zap_pfn_range(vstart, order, in_frames, NULL);
/* 2. Get a new contiguous memory extent. */
- out_frame = virt_to_pfn(vstart);
+ out_frame = virt_to_pfn((void *)vstart);
success = xen_exchange_memory(1UL << order, 0, in_frames,
1, order, &out_frame,
address_bits);
@@ -2360,7 +2360,7 @@ void xen_destroy_contiguous_region(phys_addr_t pstart,
unsigned int order)
spin_lock_irqsave(&xen_reservation_lock, flags);
/* 1. Find start MFN of contiguous extent. */
- in_frame = virt_to_mfn(vstart);
+ in_frame = virt_to_mfn((void *)vstart);
/* 2. Zap current PTEs. */
xen_zap_pfn_range(vstart, order, NULL, out_frames);
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 8b5cf7bb1f47..50c998b844fb 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -340,7 +340,7 @@ static void __init xen_do_set_identity_and_remap_chunk(
WARN_ON(size == 0);
- mfn_save = virt_to_mfn(buf);
+ mfn_save = virt_to_mfn((void *)buf);
for (ident_pfn_iter = start_pfn, remap_pfn_iter = remap_pfn;
ident_pfn_iter < ident_end_pfn;
@@ -503,7 +503,7 @@ void __init xen_remap_memory(void)
unsigned long pfn_s = ~0UL;
unsigned long len = 0;
- mfn_save = virt_to_mfn(buf);
+ mfn_save = virt_to_mfn((void *)buf);
while (xen_remap_mfn != INVALID_P2M_ENTRY) {
/* Map the remap information */
---
base-commit: 06c2afb862f9da8dc5efa4b6076a0e48c3fbaaa5
change-id: 20230808-virt-to-phy
Re: [PATCH net-next 01/14] eth: remove copies of the NAPI_POLL_WEIGHT define
On Wed, Apr 27, 2022 at 5:41 PM Jakub Kicinski wrote: > Defining local versions of NAPI_POLL_WEIGHT with the same > values in the drivers just makes refactoring harder. > > Drop the special defines in a bunch of drivers where the > removal is relatively simple so grouping into one patch > does not impact reviewability. > > Signed-off-by: Jakub Kicinski > --- > CC: ulli.kr...@googlemail.com > CC: linus.wall...@linaro.org > CC: mlind...@marvell.com > CC: step...@networkplumber.org > CC: n...@nbd.name > CC: j...@phrozen.org > CC: sean.w...@mediatek.com > CC: mark-mc@mediatek.com > CC: matthias@gmail.com > CC: grygorii.stras...@ti.com > CC: wei@kernel.org > CC: p...@xen.org > CC: prabhakar.mahadev-lad...@bp.renesas.com > CC: linux-arm-ker...@lists.infradead.org > CC: linux-media...@lists.infradead.org > CC: linux-o...@vger.kernel.org > CC: xen-devel@lists.xenproject.org Looks good to me! Reviewed-by: Linus Walleij Yours, Linus Walleij
Re: [patch 16/30] mfd: ab8500-debugfs: Remove the racy fiddling with irq_desc
On Thu, Dec 10, 2020 at 8:42 PM Thomas Gleixner wrote: > First of all drivers have absolutely no business to dig into the internals > of an irq descriptor. That's core code and subject to change. All of this > information is readily available to /proc/interrupts in a safe and race > free way. > > Remove the inspection code which is a blatant violation of subsystem > boundaries and racy against concurrent modifications of the interrupt > descriptor. > > Print the irq line instead so the information can be looked up in a sane > way in /proc/interrupts. > > Signed-off-by: Thomas Gleixner > Cc: Linus Walleij > Cc: Lee Jones > Cc: linux-arm-ker...@lists.infradead.org Reviewed-by: Linus Walleij Yours, Linus Walleij
Re: [patch 15/30] pinctrl: nomadik: Use irq_has_action()
On Thu, Dec 10, 2020 at 8:42 PM Thomas Gleixner wrote: > Let the core code do the fiddling with irq_desc. > > Signed-off-by: Thomas Gleixner > Cc: Linus Walleij > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-g...@vger.kernel.org Reviewed-by: Linus Walleij I suppose you will funnel this directly to Torvalds, else tell me and I'll apply it to my tree. Yours, Linus Walleij
[PATCH] xen/netback: Pass (void *) to virt_to_page()
virt_to_page() takes a virtual address as argument but the driver passes an unsigned long, which works because the target platform(s) uses polymorphic macros to calculate the page. Since many architectures implement virt_to_pfn() as a macro, this function becomes polymorphic and accepts both a (unsigned long) and a (void *). Fix this up by an explicit (void *) cast. Cc: Wei Liu Cc: Paul Durrant Cc: xen-devel@lists.xenproject.org Cc: net...@vger.kernel.org Signed-off-by: Linus Walleij --- drivers/net/xen-netback/netback.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c index c1501f41e2d8..caf0c815436c 100644 --- a/drivers/net/xen-netback/netback.c +++ b/drivers/net/xen-netback/netback.c @@ -689,7 +689,7 @@ static void xenvif_fill_frags(struct xenvif_queue *queue, struct sk_buff *skb) prev_pending_idx = pending_idx; txp = &queue->pending_tx_info[pending_idx].req; - page = virt_to_page(idx_to_kaddr(queue, pending_idx)); + page = virt_to_page((void *)idx_to_kaddr(queue, pending_idx)); __skb_fill_page_desc(skb, i, page, txp->offset, txp->size); skb->len += txp->size; skb->data_len += txp->size; -- 2.34.1
Re: [PATCH] xen/netback: Pass (void *) to virt_to_page()
On Thu, May 25, 2023 at 7:12 AM Jakub Kicinski wrote: > On Wed, 24 May 2023 22:11:47 -0700 Jakub Kicinski wrote: > > On Tue, 23 May 2023 16:03:42 +0200 Linus Walleij wrote: > > > virt_to_page() takes a virtual address as argument but > > > the driver passes an unsigned long, which works because > > > the target platform(s) uses polymorphic macros to calculate > > > the page. > > > > > > Since many architectures implement virt_to_pfn() as > > > a macro, this function becomes polymorphic and accepts both a > > > (unsigned long) and a (void *). > > > > > > Fix this up by an explicit (void *) cast. > > > > Paul, Wei, looks like netdev may be the usual path for this patch > > to flow thru, although I'm never 100% sure with Xen. > > Please ack or LUK if you prefer to direct the patch elsewhere? > > Ugh, Wei already acked this, sorry for the noise. Don't worry about it Jakub, it's queued in the asm-generic tree along with patches making things give nasty compile messages if they are not typed right, we try to keep down the level of noise this way: silence it while fixing the root cause. If you prefer to take it into the net tree that works too but no need. Yours, Linus Walleij
Re: [PATCH -next v6 1/8] entry: Split generic entry into generic exception and syscall entry
> Currently CONFIG_GENERIC_ENTRY enables both the generic exception > entry logic and the generic syscall entry logic, which are otherwise > loosely coupled. > > Introduce separate config options for these so that archtiectures can > select the two independently. This will make it easier for > architectures to migrate to generic entry code. > > Suggested-by: Mark Rutland > Signed-off-by: Jinjie Ruan If the generic entry maintainer (hi Thomas) thinks this patch is OK it would be nice to have it applied because it will also make the ARM32 transition to generic entry easier as we can work on exception and syscall entry each in isolation. Acked-by: Linus Walleij Yours, Linus Walleij
