Re: [PATCH v4 1/8] xen/domain: introduce common emulation flags

["Roger Pau Monné" <roger.pau@citrix.com>]

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

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:

#define _XEN_X86_EMU_VUART          11
#define XEN_X86_EMU_VUART           (1U << _XEN_X86_EMU_VUART)

Thanks, Roger.