[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [Minios-devel] [PATCH v4 0/<VARIOUS>] Begin to disentangle libxenctrl and provide some stable libraries
I've just sent out v5. Anyone got any thoughts on how to proceed with qemu- xen? On Wed, 2015-10-21 at 16:47 +0100, Ian Campbell wrote: > (Trimming CCs a bit) > > On Wed, 2015-10-21 at 16:22 +0100, Ian Campbell wrote: > > > [...] > > Still to come would be libraries for specific out of tree purposes > > (device model, kexec), which would be adding new library at the same > > level as libxc I think, rather than underneath, i.e. also using the > > libraries split out here, but hopefully not libxenctrl itself. > > Next steps for qemu-xen, with reference to: > > http://xenbits.xen.org/people/ianc/libxenctrl-split/v4.html#by-functional-area > > First the two simple cases: > > The PV backend support now only (I think) uses got from these new libraries. > > The PV domain builder is now configured off by default, I don't intend to > make this > use a stable API so when enabling this qemu will then be linked against the > unstable > libxen{guest,ctrl} libraries. > > Now the more complex cases. > > The actual DM functionality looks in reasonably good shape, from the > pandoc > source to the above (the "S" columns represent whether the column to the > left is a stable interface or not): > > InterfaceÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂS Underlying InterfaceÂÂÂÂÂÂÂÂÂÂÂS Other > users > ---------------------------------- - ------------------------------ - > --------------- > `xenevtchn_bind_interdomain`ÂÂÂÂÂÂÂY > `xenevtchn_close`ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂY > `xenevtchn_fd`ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂY > `xenevtchn_notify`ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂY > `xenevtchn_open`ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂY > `xenevtchn_pending`ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂY > `xenevtchn_unmask`ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂY > `xenforeignmemory_map`ÂÂÂÂÂÂÂÂÂÂÂÂÂY > `xenforeignmemory_open`ÂÂÂÂÂÂÂÂÂÂÂÂY > `xenforeignmemory_unmap`ÂÂÂÂÂÂÂÂÂÂÂY > `xc_domain_add_to_physmap`ÂÂÂÂÂÂÂÂÂN `XENMEM_add_to_physmap`ÂÂÂÂÂÂÂÂY libxc > (dombuilder) > `xc_domain_populate_physmap_exact` N `XENMEM_populate_physmap`ÂÂÂÂÂÂY libxc > (several) > `xc_domain_pin_memory_cacheattr`ÂÂÂN `XEN_DOMCTL_pin_mem_cacheattr` N None > `xc_domain_shutdown`ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂN `SCHEDOP_remote_shutdown`ÂÂÂÂÂÂY libxl > `xc_set_hvm_param`ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂN `HVM_PARAM_ACPI_S_STATE`ÂÂÂÂÂÂÂY None > `xc_hvm_inject_msi`ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂN `HVMOP_inject_msi`ÂÂÂÂÂÂÂÂÂÂÂÂÂY None > `xc_hvm_modified_memory`ÂÂÂÂÂÂÂÂÂÂÂN `HVMOP_modified_memory`ÂÂÂÂÂÂÂÂY None > `xc_hvm_set_isa_irq_level`ÂÂÂÂÂÂÂÂÂN `HVMOP_set_isa_irq_level`ÂÂÂÂÂÂY None > `xc_hvm_set_mem_type`ÂÂÂÂÂÂÂÂÂÂÂÂÂÂN `HVMOP_set_mem_type`ÂÂÂÂÂÂÂÂÂÂÂY None > `xc_hvm_set_pci_intx_level`ÂÂÂÂÂÂÂÂN `HVMOP_set_pci_intx_level`ÂÂÂÂÂY None > `xc_hvm_set_pci_link_route`ÂÂÂÂÂÂÂÂN `HVMOP_set_pci_link_route`ÂÂÂÂÂY None > `xc_hvm_track_dirty_vram`ÂÂÂÂÂÂÂÂÂÂN `HVMOP_track_dirty_vram`ÂÂÂÂÂÂÂY None > `xc_hvm_unmap_io_range_from_ir...` N `HVMOP_IO_RANGE_(PORT|MEM...)` Y None > `xc_hvm_unmap_pcidev_from_iore...` N `HVMOP_unmap_io_range_from...` Y None > > I think it would be reasonable to add a new library (say, > libxendevicemodel, for arguments sake) with a stable ABI and to move all > of the xc_hvm_* above into it. They are not used for anything else and > are based on HVMOP which is a stable interface (AFAIK). > > Within qemu xc_domain_add_to_physmap and xc_domain_pin_memory_cacheattr are > used in tandem solely to populate VRAM with WB memory and to remove again. > > xc_domain_populate_physmap_exact is used only to populate RAM and > xc_domain_shutdown is used on shutdown. > > I think having three or four functions in libxendevicemodel which offer > these exact facilities while retaining the underlying (possibly more > flexible) functionality in libxenctrl for other users (dombuilder, other in > tree tools) would be tolerable. > > Three or four functions depends on whether the uses of > xc_domain_add_to_physmap+xc_domain_pin_memory_cacheattr and > xc_domain_populate_physmap_exact can be satisfied with a single API or not. > I don't know that yet. > > The main question would then be whether libxendevicemodel should wrap > libxenctrl in a stable layer or whether it should actually duplicate the > functionality in the thin wrappers. > > Wrapping libxenctrl would mean that libxendevicemodel would need to be > built by all releases with a fixed ABI such that the corresponding one > (linking against the correct libxenctrl) can be flipped into place on boot. > I think that is going to be too tricky for distros and users a like and > that the small amount of duplication is therefore more tolerable. > > The only blocker for that is that xc_domain_pin_memory_cacheattr is > XEN_DOMCTL_pin_mem_cacheattr (i.e. not stable), but this route would either > require it to move to a stable hypercall interface or for the library to > DTRT for all versions. I think moving to a stable h/call interface is more > feasible. > > In terms of deprivileging QEMU (one of the end goals of this work) I think > all the xen* libraries could very easily gain a xen???_set_target_domain > which would make an appropriate ioctl to lock the underlying fd into > operating only on that domain (another argument in finding a way to do > pin_mem_cacheattr as a stable API). This would require support from all the > underlying drivers, but could be added right away with errno=ENOTTY + > return -1 and then plumbed in later. Obviously qemu would need to check the > return values. > > The PCI passthrough case is less clear: > > InterfaceÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂS Underlying InterfaceÂÂÂÂÂÂÂÂÂÂÂS Other > users > ---------------------------------- - ------------------------------ - > --------------- > `xc_domain_bind_pt_pci_irq`ÂÂÂÂÂÂÂÂN `XEN_DOMCTL_bind_pt_irq`ÂÂÂÂÂÂÂN None > `xc_domain_ioport_mapping`ÂÂÂÂÂÂÂÂÂN `XEN_DOMCTL_ioport_mapping`ÂÂÂÂN None > `xc_domain_memory_mapping`ÂÂÂÂÂÂÂÂÂN `XEN_DOMCTL_memory_mapping`ÂÂÂÂN libxl > `xc_domain_unbind_msi_irq`ÂÂÂÂÂÂÂÂÂN `XEN_DOMCTL_unbind_pt_irq`ÂÂÂÂÂN None > `xc_domain_unbind_pt_irq`ÂÂÂÂÂÂÂÂÂÂN `XEN_DOMCTL_unbind_pt_irq`ÂÂÂÂÂN None > `xc_domain_update_msi_irq`ÂÂÂÂÂÂÂÂÂN `XEN_DOMCTL_bind_pt_irq`ÂÂÂÂÂÂÂN None > `xc_physdev_map_pirq`ÂÂÂÂÂÂÂÂÂÂÂÂÂÂN `PHYSDEVOP_map_pirq`ÂÂÂÂÂÂÂÂÂÂÂY libxl > `xc_physdev_map_pirq_msi`ÂÂÂÂÂÂÂÂÂÂN `PHYSDEVOP_map_pirq`ÂÂÂÂÂÂÂÂÂÂÂY None > `xc_physdev_unmap_pirq`ÂÂÂÂÂÂÂÂÂÂÂÂN `PHYSDEVOP_unmap_pirq`ÂÂÂÂÂÂÂÂÂY libxl > > NB: More might be used by libxl in the future e.g. for ARM or PVH > passthrough? > > It seems like much of this would be candidates for adding to > libxendevicemodel, but the underlying unstable interfaces pose a problem > there. I'm going to leave this for another day. > > Ian. > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxx > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |