[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v4 3/8] x86/domain: allocate d->{iomem,irq}_caps before arch-specific initialization



On Wed, Aug 06, 2025 at 04:37:23PM +0200, Roger Pau Monné wrote:
> On Thu, Jul 31, 2025 at 07:21:54PM +0000, dmkhn@xxxxxxxxx wrote:
> > From: Denis Mukhin <dmukhin@xxxxxxxx>
> >
> > Move IRQ/IOMEM rangesets allocation before arch_domain_create().
> >
> > That guarantees that arch-specific code could access those rangesets to
> > register traps for emulation.
> >
> > It is necessary for those emulators registering trap handlers and ensuring
> > that emulated IRQs are not shared with the physical IRQs.
> >
> > Move dom0_setup_permissions() call right after I/O rangesets are allocated.
> >
> > Move pvh_setup_mmcfg() inside dom0_setup_permissions() close to the place
> > where MMCFG ranges are initialized.
> 
> I'm a bit puzzled by this, you don't need I/O permission to setup
> traps.  You can setup traps everywhere, the I/O rangesets control
> whether a domain can access the physical resource, not whether
> accesses can be emulated.

I do not want to setup traps if there's physical I/O range owned by the same
domain already. Emulator will report a misconfiguration in this case.

> 
> The dependency between MMCFG registration (pvh_setup_mmcfg()) and
> calling dom0_setup_permissions() is because the later consumes the
> MMCFG ranges added by the former to mark them as not accessible by
> a PVH dom0.
> 
> I think you don't need this for vUARTS, as the ports are know at build
> time, and hence you can block access to them without requiring the
> actual vUART to be initialized.

Oh, I see now why I have it: that spilled from MMIO-based UART.

What I need is I/O ports and IRQs rangesets allocation before emulator
initialization.

> 
> Thanks, Roger.




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.