On 17.03.2025 17:23, Jan Beulich wrote: > On 17.03.2025 17:17, Jason Andryuk wrote: >> On 2025-03-17 10:28, Jan Beulich wrote: >>> On 06.03.2025 23:03, Jason Andryuk wrote: >>>> Allow hwdom all perms, except XSM_PRIV, and except commands where the >>>> target is the control domain. This protects the control domain from >>>> hwdom while allowing the hardware domain to serve as the backend and >>>> device model for other domUs. >>> >>> I can see why backends may need to live there. But device models don't >>> belong in the hardware domain, do they? >> >> One of my tests was on x86 with hardware domain running QEMU providing >> virtio-gpu to a domU. QEMU needs to access the GPU for virtio-gpu. >> Also HVM/QEMU PCI passthrough would need to run from hardware domain. >> for the config space access. >> >> I viewed the hardware domain as the place to run the device model - sort >> of like a stubdom moving out of dom0. > > Hmm, yes, when dealing with hardware made accessible to a guest, the DM > would need to live in hwdom (in the absence of stubdom-s). For non-pass- > through guests that's less clear though.
So perhaps I'm in (conceptual) trouble with this kind of dis-aggregation: To split ctrldom from hwdom without moving DMs to stubdom-s feels a little "incomplete" to me. Jan
