On Tue, Sep 21, 2021 at 09:17:37AM +0200, Jan Beulich wrote: > Certain notifications of Dom0 to Xen are independent of the mode Dom0 is > running in. Permit further PCI related ones (only their modern forms). > Also include the USB2 debug port operation at this occasion. > > Signed-off-by: Jan Beulich <jbeul...@suse.com> > --- > I'm uncertain about the has_vpci() part of the check: I would think > is_hardware_domain() is both sufficient and concise. Without vPCI a PVH > Dom0 won't see any PCI devices in the first place (and hence would > effectively be non-functioning). Dropping this would in particular make > PHYSDEVOP_dbgp_op better fit in the mix. > --- > v3: New. > > --- a/xen/arch/x86/hvm/hypercall.c > +++ b/xen/arch/x86/hvm/hypercall.c > @@ -94,6 +94,12 @@ static long hvm_physdev_op(int cmd, XEN_ > break; > > case PHYSDEVOP_pci_mmcfg_reserved: > + case PHYSDEVOP_pci_device_add: > + case PHYSDEVOP_pci_device_remove: > + case PHYSDEVOP_restore_msi_ext:
Hm, I'm slightly unsure we need the restore operation. Wouldn't it be better to just reset all device state on suspend and then let dom0 restore it's state as it does on native? Maybe there's some wrinkle that prevents that from working properly. > + case PHYSDEVOP_dbgp_op: > + case PHYSDEVOP_prepare_msix: > + case PHYSDEVOP_release_msix: Albeit I think those two operations won't strictly conflict with vPCI usage (as they require no MSIX entries to be activ) I still wonder whether we will end up needing them on a PVH dom0. They are used by pciback and it's not yet clear how we will end up using pciback on a PVH dom0, hence I would prefer if we could leave them out until strictly required. Thanks, Roger.
