[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v4 1/8] xen/domain: introduce common emulation flags
On Tue, Aug 05, 2025 at 12:54:31AM +0000, dmkhn@xxxxxxxxx wrote: > + Cc: Oleskii > > On Mon, Aug 04, 2025 at 11:46:36AM +0200, Jan Beulich wrote: > > On 31.07.2025 21:21, dmkhn@xxxxxxxxx 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.
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |