From: "Roger Pau Monné" <roger.pau@citrix.com>
To: dmkhn@proton.me
Cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com,
anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org,
michal.orzel@amd.com, sstabellini@kernel.org, dmukhin@ford.com
Subject: Re: [PATCH v4 5/8] emul/vuart-ns16550: introduce NS16550-compatible UART emulator (x86)
Date: Wed, 6 Aug 2025 19:24:29 +0200 [thread overview]
Message-ID: <aJOPzSluXlDgBP-g@macbook.local> (raw)
In-Reply-To: <aJNvcLgsUOahsQZl@macbook.local>
On Wed, Aug 06, 2025 at 05:06:24PM +0200, Roger Pau Monné wrote:
> On Thu, Jul 31, 2025 at 07:22:06PM +0000, dmkhn@proton.me wrote:
> > From: Denis Mukhin <dmukhin@ford.com>
> Overall I agree for Jan it would be better if this patch could be
> split into somehow smaller units. Is this something feasible? We
> don't want a patch for each register handle, but maybe you cna somehow
> grup those into functional sections, so that patches can be < 250
> lines?
I've been thinking about this, would it be feasible to have a first
patch that introduces all the boilerplate, like adding the domain
create option, wire the libxl bits, but doesn't actually add any
emulation at all. Then further patches could fill in the emulation
slowly, starting with a patch to register the IO port handlers
(initially would be empty functions), and progressing from the basic
parts (uart initialization maybe?) towards the end implementation that
you have here.
Thanks, Roger.
next prev parent reply other threads:[~2025-08-06 17:25 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-31 19:21 [PATCH v4 0/8] x86: introduce NS16550-compatible UART emulator dmkhn
2025-07-31 19:21 ` [PATCH v4 1/8] xen/domain: introduce common emulation flags dmkhn
2025-08-04 9:46 ` Jan Beulich
2025-08-05 0:54 ` dmkhn
2025-08-06 13:56 ` Roger Pau Monné
2025-08-07 17:54 ` dmkhn
2025-08-07 14:28 ` Oleksii Kurochko
2025-08-07 17:43 ` dmkhn
2025-07-31 19:21 ` [PATCH v4 2/8] emul/vuart: introduce framework for UART emulators dmkhn
2025-08-01 0:08 ` Stefano Stabellini
2025-08-01 2:54 ` dmkhn
2025-08-04 10:11 ` Jan Beulich
2025-08-09 18:55 ` dmkhn
2025-08-11 7:34 ` Jan Beulich
2025-08-11 23:55 ` dmkhn
2025-08-12 6:52 ` Jan Beulich
2025-08-14 6:32 ` dmkhn
2025-08-06 14:24 ` Roger Pau Monné
2025-08-07 19:12 ` dmkhn
2025-07-31 19:21 ` [PATCH v4 3/8] x86/domain: allocate d->{iomem,irq}_caps before arch-specific initialization dmkhn
2025-07-31 19:52 ` Grygorii Strashko
2025-07-31 20:21 ` dmkhn
2025-08-01 2:57 ` dmkhn
2025-07-31 23:20 ` Stefano Stabellini
2025-08-04 10:20 ` Jan Beulich
2025-08-07 18:59 ` dmkhn
2025-08-06 14:37 ` Roger Pau Monné
2025-08-07 18:57 ` dmkhn
2025-07-31 19:22 ` [PATCH v4 4/8] xen/8250-uart: update definitions dmkhn
2025-07-31 23:23 ` Stefano Stabellini
2025-08-04 10:23 ` Jan Beulich
2025-08-07 19:41 ` dmkhn
2025-07-31 19:22 ` [PATCH v4 5/8] emul/vuart-ns16550: introduce NS16550-compatible UART emulator (x86) dmkhn
2025-07-31 23:57 ` Stefano Stabellini
2025-08-01 3:28 ` dmkhn
2025-08-04 10:53 ` Jan Beulich
2025-08-09 18:37 ` dmkhn
2025-08-11 7:39 ` Jan Beulich
2025-08-12 0:06 ` dmkhn
2025-08-06 15:06 ` Roger Pau Monné
2025-08-06 17:24 ` Roger Pau Monné [this message]
2025-08-07 18:49 ` dmkhn
2025-07-31 19:22 ` [PATCH v4 6/8] tools/xl: enable NS16550-compatible UART emulator for HVM (x86) dmkhn
2025-08-04 10:54 ` Jan Beulich
2025-08-06 15:21 ` Roger Pau Monné
2025-08-25 14:49 ` Anthony PERARD
2025-08-25 15:03 ` Jan Beulich
2025-08-25 15:13 ` Anthony PERARD
2025-08-25 15:27 ` Jan Beulich
2025-08-25 15:39 ` Anthony PERARD
2025-08-25 15:45 ` Jan Beulich
2025-08-26 9:26 ` dmkhn
2025-07-31 19:22 ` [PATCH v4 7/8] tools/xl: enable NS16550-compatible UART emulator for PVH (x86) dmkhn
2025-08-01 0:46 ` Stefano Stabellini
2025-08-01 1:53 ` dmkhn
2025-08-04 11:06 ` Jan Beulich
2025-08-07 19:38 ` dmkhn
2025-07-31 19:22 ` [PATCH v4 8/8] emul/vuart: introduce console forwarding enforcement via vUART dmkhn
2025-08-01 0:10 ` Stefano Stabellini
2025-08-01 1:51 ` dmkhn
2025-08-06 13:48 ` [PATCH v4 0/8] x86: introduce NS16550-compatible UART emulator Roger Pau Monné
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=aJOPzSluXlDgBP-g@macbook.local \
--to=roger.pau@citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=anthony.perard@vates.tech \
--cc=dmkhn@proton.me \
--cc=dmukhin@ford.com \
--cc=jbeulich@suse.com \
--cc=julien@xen.org \
--cc=michal.orzel@amd.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.