All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Marczykowski <marmarek@invisiblethingslab.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Julien Grall" <julien@xen.org>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Anthony PERARD" <anthony.perard@vates.tech>,
	"Michal Orzel" <michal.orzel@amd.com>,
	"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [PATCH 3/3] xhci-dbc: use brk_alloc()
Date: Thu, 13 Nov 2025 13:39:16 +0100	[thread overview]
Message-ID: <aRXRdU8YusudRmxf@mail-itl> (raw)
In-Reply-To: <bec55a88-00f3-4961-b1dc-5b9e38d94a32@suse.com>

[-- Attachment #1: Type: text/plain, Size: 3403 bytes --]

On Thu, Nov 13, 2025 at 12:10:16PM +0100, Jan Beulich wrote:
> This way the relatively large chunk of DMA buffers can be freed when the
> driver isn't in use.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/drivers/char/xhci-dbc.c
> +++ b/xen/drivers/char/xhci-dbc.c
> @@ -27,6 +27,8 @@
>  #include <xen/serial.h>
>  #include <xen/timer.h>
>  #include <xen/types.h>
> +
> +#include <asm/brk.h>
>  #include <asm/fixmap.h>
>  #include <asm/io.h>
>  #include <asm/string.h>
> @@ -1321,7 +1323,7 @@ static struct uart_driver dbc_uart_drive
>  };
>  
>  /* Those are accessed via DMA. */
> -struct dbc_dma_bufs {
> +struct __aligned(PAGE_SIZE) dbc_dma_bufs {
>      struct xhci_trb evt_trb[DBC_TRB_RING_CAP];
>      struct xhci_trb out_trb[DBC_TRB_RING_CAP];
>      struct xhci_trb in_trb[DBC_TRB_RING_CAP];
> @@ -1335,8 +1337,7 @@ struct dbc_dma_bufs {
>       * DMA-reachable by the USB controller.
>       */
>  };
> -static struct dbc_dma_bufs __section(".bss.page_aligned") __aligned(PAGE_SIZE)
> -    dbc_dma_bufs;
> +DEFINE_BRK(xhci, sizeof(struct dbc_dma_bufs));

I think with this change (or rather with using brk_alloc() below), the
structure wants to be padded up to the page size, to avoid putting
anything else on the same page (see comment just outside of context
above). Previously .bss.page_aligned contained (hopefully) only
page-aligned objects, but now brk_alloc() can combine them.

>  
>  static int __init cf_check xhci_parse_dbgp(const char *opt_dbgp)
>  {
> @@ -1413,24 +1414,33 @@ void __init xhci_dbc_uart_init(void)
>  {
>      struct dbc_uart *uart = &dbc_uart;
>      struct dbc *dbc = &uart->dbc;
> +    struct dbc_dma_bufs *dma_bufs;
>  
>      if ( !dbc->enable )
>          return;
>  
> -    dbc->dbc_ctx = &dbc_dma_bufs.ctx;
> -    dbc->dbc_erst = &dbc_dma_bufs.erst;
> -    dbc->dbc_ering.trb = dbc_dma_bufs.evt_trb;
> -    dbc->dbc_oring.trb = dbc_dma_bufs.out_trb;
> -    dbc->dbc_iring.trb = dbc_dma_bufs.in_trb;
> -    dbc->dbc_owork.buf = dbc_dma_bufs.out_wrk_buf;
> -    dbc->dbc_iwork.buf = dbc_dma_bufs.in_wrk_buf;
> -    dbc->dbc_str = dbc_dma_bufs.str_buf;
> +    dma_bufs = brk_alloc(sizeof(*dma_bufs));
> +    if ( !dma_bufs )
> +    {
> +        dbc->enable = false;
> +        printk(XENLOG_ERR "XHCI: not enough BRK space available\n");
> +        return;
> +    }
> +
> +    dbc->dbc_ctx = &dma_bufs->ctx;
> +    dbc->dbc_erst = &dma_bufs->erst;
> +    dbc->dbc_ering.trb = dma_bufs->evt_trb;
> +    dbc->dbc_oring.trb = dma_bufs->out_trb;
> +    dbc->dbc_iring.trb = dma_bufs->in_trb;
> +    dbc->dbc_owork.buf = dma_bufs->out_wrk_buf;
> +    dbc->dbc_iwork.buf = dma_bufs->in_wrk_buf;
> +    dbc->dbc_str = dma_bufs->str_buf;
>  
>      if ( dbc_open(dbc) )
>      {
>          iommu_add_extra_reserved_device_memory(
> -                PFN_DOWN(virt_to_maddr(&dbc_dma_bufs)),
> -                PFN_UP(sizeof(dbc_dma_bufs)),
> +                PFN_DOWN(virt_to_maddr(dma_bufs)),
> +                PFN_DOWN(sizeof(*dma_bufs)),

Is that really correct? But with padding (see earlier comment) it
shouldn't really matter.

>                  uart->dbc.sbdf,
>                  "XHCI console");
>          serial_register_uart(SERHND_XHCI, &dbc_uart_driver, &dbc_uart);
> 

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2025-11-13 12:39 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-13 11:06 [PATCH 0/3] x86: "brk" allocator Jan Beulich
2025-11-13 11:08 ` [PATCH 1/3] x86: introduce " Jan Beulich
2025-11-13 17:41   ` Marek Marczykowski-Górecki
2025-11-14  7:56     ` Jan Beulich
2025-11-13 11:09 ` [PATCH 2/3] x86/EFI: replace ebmalloc() Jan Beulich
2025-11-13 12:40   ` Marek Marczykowski
2025-11-13 12:46     ` Jan Beulich
2025-11-13 12:59       ` Marek Marczykowski
2025-11-13 13:24         ` Jan Beulich
2025-11-13 17:30           ` Marek Marczykowski
2025-11-13 12:53     ` Jan Beulich
2025-11-13 13:01       ` Marek Marczykowski
2025-11-13 11:10 ` [PATCH 3/3] xhci-dbc: use brk_alloc() Jan Beulich
2025-11-13 12:39   ` Marek Marczykowski [this message]
2025-11-13 12:50     ` Jan Beulich
2025-11-13 13:01       ` Marek Marczykowski
2025-11-13 15:29 ` [PATCH 0/3] x86: "brk" allocator Andrew Cooper

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aRXRdU8YusudRmxf@mail-itl \
    --to=marmarek@invisiblethingslab.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=anthony.perard@vates.tech \
    --cc=jbeulich@suse.com \
    --cc=julien@xen.org \
    --cc=michal.orzel@amd.com \
    --cc=roger.pau@citrix.com \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.