From: dmkhn@proton.me
To: "Roger Pau Monné" <roger.pau@citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>,
andrew.cooper3@citrix.com, anthony.perard@vates.tech,
julien@xen.org, michal.orzel@amd.com, sstabellini@kernel.org,
oleksii.kurochko@gmail.com, dmukhin@ford.com,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH v4 1/8] xen/domain: introduce common emulation flags
Date: Thu, 07 Aug 2025 17:54:01 +0000 [thread overview]
Message-ID: <aJToNFZ6z49nqAsF@kraken> (raw)
In-Reply-To: <aJNfGqiTDH991_8L@macbook.local>
On Wed, Aug 06, 2025 at 03:56:42PM +0200, Roger Pau Monné wrote:
> On Tue, Aug 05, 2025 at 12:54:31AM +0000, dmkhn@proton.me wrote:
> > + Cc: Oleskii
> >
> > On Mon, Aug 04, 2025 at 11:46:36AM +0200, Jan Beulich wrote:
> > > On 31.07.2025 21:21, dmkhn@proton.me wrote:
> > > > --- a/xen/include/xen/sched.h
> > > > +++ b/xen/include/xen/sched.h
> > > > @@ -652,6 +652,8 @@ struct domain
> > > > unsigned int *llc_colors;
> > > > #endif
> > > >
> > > > + uint32_t emulation_flags;
> > >
> > > Just one further remark: The field probably never should have been of this
> > > type; unsigned int will do, and imo will want switching to while the field
> > > is being moved. (Before giving an x86 ack, I want to convince myself though
> > > that this is moving us in the right direction.)
> >
> > Hi Jan,
> >
> > I can definitely use different mechanism for virt ns16550: add a new field in
> > xen_arch_domainconfig. That will also simplify some of the emulation_flags
> > checks on x86 and will be more flexible wrt emulator configuration (e.g. I can
> > allow passing I/O ports ranges).
>
> For the time being, I would leave emulation_flags in
> xen_arch_domainconfig.
Ack; agreed.
> The set of emulated devices is
> architecture-specific, and pulling it to the generic struct is IMO not
> specially helpful, as you then have the definition of the flags
> decoupled from the field definition.
NS16550 is not an arch-specific device though.
But yes, current implementation _is_ arch-specific.
>
> For the emulated UART, I don't think you need a new field in
> xen_arch_domainconfig, just a new bit in emulation_flags? IOW:
I think new field is needed, since there are four legacy PC UART resource
sets selectable by the user. I'm dropping COM port build-time selection
and reworking it to be xl-configurable. That will be more flexible and
there will be less in-hypervisor changes.
>
> #define _XEN_X86_EMU_VUART 11
> #define XEN_X86_EMU_VUART (1U << _XEN_X86_EMU_VUART)
>
> Thanks, Roger.
next prev parent reply other threads:[~2025-08-07 17:54 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 [this message]
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é
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=aJToNFZ6z49nqAsF@kraken \
--to=dmkhn@proton.me \
--cc=andrew.cooper3@citrix.com \
--cc=anthony.perard@vates.tech \
--cc=dmukhin@ford.com \
--cc=jbeulich@suse.com \
--cc=julien@xen.org \
--cc=michal.orzel@amd.com \
--cc=oleksii.kurochko@gmail.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.