Re: [libvirt] [PATCH v3 0/5] libxl: PVHv2 support
On 10/2/18 7:05 PM, Jim Fehlig wrote: On 10/2/18 3:38 PM, Jim Fehlig wrote: On 9/30/18 8:15 PM, Marek Marczykowski-Górecki wrote: This is a respin of my old PVHv1 patch[1], converted to PVHv2. Should the code use "PVH" name (as libxl does internally), or "PVHv2" as in many places in Xen documentation? I've chosen the former, but want to confirm it. "PVH". Also, not sure about VIR_DOMAIN_OSTYPE_XENPVH (as discussed on PVHv1 patch) - while it will be messy in many cases, there is libxl_domain_build_info.u.{hvm,pv,pvh} which would be good to not mess up. Also, PVHv2 needs different kernel features than PV (CONFIG_XEN_PVH vs CONFIG_XEN_PV), so keeping the same VIR_DOMAIN_OSTYPE_XEN could be confusing. These are good reasons for going with VIR_DOMAIN_OSTYPE_XENPVH. Another is it avoids the STREQ(def->os.machine, "xenpvh"), which I think others will find appealing. On the other hand, libxl_domain_build_info.u.pv is used in very few places (one section of libxlMakeDomBuildInfo), so guarding u.hvm access with VIR_DOMAIN_OSTYPE_HVM may be enough. For now I've reused VIR_DOMAIN_OSTYPE_XEN - in the driver itself, most of the code is the same as for PV. I'll reiterate my rationalization for using VIR_DOMAIN_OSTYPE_XEN for both and differentiating them with os.machine: both PV and PVH are OS types that have been modified to run on Xen. I'd still like to get some opinions from other maintainers on this. Anyone care to share their thoughts on which approach best models PVH? I've been thinking about this more and AFAIK on the qemu side the machine attribute models a chipset, e.g. hvm hvm Is it a stretch to refer to PV and PVH as chipsets? If so, my position on the fence in now leaning towards VIR_DOMAIN_OSTYPE_XENPVH :-/ We had a bit more discussion on IRC today and generally concluded VIR_DOMAIN_OSTYPE_XEN and os.machine="xenpvh" is the better approach to model PVH. Some of the rational for the conclusion (in addition to items already mentioned above) was based on info in the related Xen wiki [0] which includes - PVH is described under the "Enhancements to PV:" section - PVH is described as "fully PV kernel mode, running with paravirtualized disk and network, paravirtualized interrupts and timers, no emulated devices of any kind (and thus no qemu), no BIOS or legacy boot - but instead of requiring PV MMU, it uses the HVM hardware extensions to virtualize the pagetables, as well as system calls and other privileged operations". So PVH is the result of the evolution of PV, a PV++ or PVImproved if you will. - Once PVH is mature and well established, the community plans to remove non-PVH support from the Linux kernel. IOW the long-term plan is for PVH to become the new PV. Regards, Jim [0] https://wiki.xenproject.org/wiki/Understanding_the_Virtualization_Spectrum -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v3 0/5] libxl: PVHv2 support
On 10/2/18 3:38 PM, Jim Fehlig wrote: On 9/30/18 8:15 PM, Marek Marczykowski-Górecki wrote: This is a respin of my old PVHv1 patch[1], converted to PVHv2. Should the code use "PVH" name (as libxl does internally), or "PVHv2" as in many places in Xen documentation? I've chosen the former, but want to confirm it. "PVH". Also, not sure about VIR_DOMAIN_OSTYPE_XENPVH (as discussed on PVHv1 patch) - while it will be messy in many cases, there is libxl_domain_build_info.u.{hvm,pv,pvh} which would be good to not mess up. Also, PVHv2 needs different kernel features than PV (CONFIG_XEN_PVH vs CONFIG_XEN_PV), so keeping the same VIR_DOMAIN_OSTYPE_XEN could be confusing. These are good reasons for going with VIR_DOMAIN_OSTYPE_XENPVH. Another is it avoids the STREQ(def->os.machine, "xenpvh"), which I think others will find appealing. On the other hand, libxl_domain_build_info.u.pv is used in very few places (one section of libxlMakeDomBuildInfo), so guarding u.hvm access with VIR_DOMAIN_OSTYPE_HVM may be enough. For now I've reused VIR_DOMAIN_OSTYPE_XEN - in the driver itself, most of the code is the same as for PV. I'll reiterate my rationalization for using VIR_DOMAIN_OSTYPE_XEN for both and differentiating them with os.machine: both PV and PVH are OS types that have been modified to run on Xen. I'd still like to get some opinions from other maintainers on this. Anyone care to share their thoughts on which approach best models PVH? I've been thinking about this more and AFAIK on the qemu side the machine attribute models a chipset, e.g. hvm hvm Is it a stretch to refer to PV and PVH as chipsets? If so, my position on the fence in now leaning towards VIR_DOMAIN_OSTYPE_XENPVH :-/ Regards, Jim -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v3 0/5] libxl: PVHv2 support
On 9/30/18 8:15 PM, Marek Marczykowski-Górecki wrote: This is a respin of my old PVHv1 patch[1], converted to PVHv2. Should the code use "PVH" name (as libxl does internally), or "PVHv2" as in many places in Xen documentation? I've chosen the former, but want to confirm it. "PVH". Also, not sure about VIR_DOMAIN_OSTYPE_XENPVH (as discussed on PVHv1 patch) - while it will be messy in many cases, there is libxl_domain_build_info.u.{hvm,pv,pvh} which would be good to not mess up. Also, PVHv2 needs different kernel features than PV (CONFIG_XEN_PVH vs CONFIG_XEN_PV), so keeping the same VIR_DOMAIN_OSTYPE_XEN could be confusing. These are good reasons for going with VIR_DOMAIN_OSTYPE_XENPVH. Another is it avoids the STREQ(def->os.machine, "xenpvh"), which I think others will find appealing. On the other hand, libxl_domain_build_info.u.pv is used in very few places (one section of libxlMakeDomBuildInfo), so guarding u.hvm access with VIR_DOMAIN_OSTYPE_HVM may be enough. For now I've reused VIR_DOMAIN_OSTYPE_XEN - in the driver itself, most of the code is the same as for PV. I'll reiterate my rationalization for using VIR_DOMAIN_OSTYPE_XEN for both and differentiating them with os.machine: both PV and PVH are OS types that have been modified to run on Xen. I'd still like to get some opinions from other maintainers on this. Anyone care to share their thoughts on which approach best models PVH? (Perhaps trying to add PVH support in virt-manager on top of this series will help flesh out the better approach. I'll give it a try...) Regards, Jim Since PVHv2 relies on features in newer Xen versions, I needed to convert also some older code. For example b_info->u.hvm.nested_hvm was deprecated in favor of b_info->nested_hvm. While the code do handle both old and new versions (obviously refusing PVHv2 if Xen is too old), this isn't the case for tests. How it should be handled, if at all? First few preparatory patches can be applied independently. [1] https://www.redhat.com/archives/libvir-list/2016-August/msg00376.html Changes in v2: - drop "docs: don't refer to deprecated 'linux' ostype in example" patch - migrating further away from "linux" os type is offtopic to this series and apparently is a controversial thing - drop "docs: update domain schema for machine attribute" patch - already applied - apply review comments from Jim - rebase on master Changes in v3: - rebase on master, drop already applied patches - use #ifdef LIBXL_DOMAIN_TYPE_PVH to detect PVH support, fix compilation failure on older Xen - exclude PVH from VIR_DOMAIN_OSTYPE_XEN <-> VIR_DOMAIN_OSTYPE_LINUX conversion - fix reported capabilities for PVH Marek Marczykowski-Górecki (5): libxl: reorder libxlMakeDomBuildInfo for upcoming PVH support libxl: add support for PVH tests: add basic Xen PVH test xenconfig: add support for parsing type= xl config entry xenconfig: add support for type="pvh" docs/formatcaps.html.in | 4 +- docs/schemas/domaincommon.rng | 1 +- src/conf/domain_conf.c | 6 +- src/libxl/libxl_capabilities.c | 47 +++--- src/libxl/libxl_conf.c | 76 -- src/libxl/libxl_driver.c| 6 +- src/xenconfig/xen_common.c | 27 ++-- src/xenconfig/xen_xl.c | 5 +- tests/libxlxml2domconfigdata/basic-pvh.json | 49 ++- tests/libxlxml2domconfigdata/basic-pvh.xml | 28 - tests/libxlxml2domconfigtest.c | 3 +- tests/testutilsxen.c| 3 +- tests/xlconfigdata/test-fullvirt-type.cfg | 21 ++- tests/xlconfigdata/test-fullvirt-type.xml | 27 - tests/xlconfigdata/test-paravirt-type.cfg | 13 - tests/xlconfigdata/test-paravirt-type.xml | 25 +++- tests/xlconfigdata/test-pvh-type.cfg| 13 - tests/xlconfigdata/test-pvh-type.xml| 25 +++- tests/xlconfigtest.c| 3 +- 19 files changed, 346 insertions(+), 36 deletions(-) create mode 100644 tests/libxlxml2domconfigdata/basic-pvh.json create mode 100644 tests/libxlxml2domconfigdata/basic-pvh.xml create mode 100644 tests/xlconfigdata/test-fullvirt-type.cfg create mode 100644 tests/xlconfigdata/test-fullvirt-type.xml create mode 100644 tests/xlconfigdata/test-paravirt-type.cfg create mode 100644 tests/xlconfigdata/test-paravirt-type.xml create mode 100644 tests/xlconfigdata/test-pvh-type.cfg create mode 100644 tests/xlconfigdata/test-pvh-type.xml base-commit: 199eee6aae7af3d813fbe98660c7e0fa1a8ae7b7 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH v3 0/5] libxl: PVHv2 support
This is a respin of my old PVHv1 patch[1], converted to PVHv2. Should the code use "PVH" name (as libxl does internally), or "PVHv2" as in many places in Xen documentation? I've chosen the former, but want to confirm it. Also, not sure about VIR_DOMAIN_OSTYPE_XENPVH (as discussed on PVHv1 patch) - while it will be messy in many cases, there is libxl_domain_build_info.u.{hvm,pv,pvh} which would be good to not mess up. Also, PVHv2 needs different kernel features than PV (CONFIG_XEN_PVH vs CONFIG_XEN_PV), so keeping the same VIR_DOMAIN_OSTYPE_XEN could be confusing. On the other hand, libxl_domain_build_info.u.pv is used in very few places (one section of libxlMakeDomBuildInfo), so guarding u.hvm access with VIR_DOMAIN_OSTYPE_HVM may be enough. For now I've reused VIR_DOMAIN_OSTYPE_XEN - in the driver itself, most of the code is the same as for PV. Since PVHv2 relies on features in newer Xen versions, I needed to convert also some older code. For example b_info->u.hvm.nested_hvm was deprecated in favor of b_info->nested_hvm. While the code do handle both old and new versions (obviously refusing PVHv2 if Xen is too old), this isn't the case for tests. How it should be handled, if at all? First few preparatory patches can be applied independently. [1] https://www.redhat.com/archives/libvir-list/2016-August/msg00376.html Changes in v2: - drop "docs: don't refer to deprecated 'linux' ostype in example" patch - migrating further away from "linux" os type is offtopic to this series and apparently is a controversial thing - drop "docs: update domain schema for machine attribute" patch - already applied - apply review comments from Jim - rebase on master Changes in v3: - rebase on master, drop already applied patches - use #ifdef LIBXL_DOMAIN_TYPE_PVH to detect PVH support, fix compilation failure on older Xen - exclude PVH from VIR_DOMAIN_OSTYPE_XEN <-> VIR_DOMAIN_OSTYPE_LINUX conversion - fix reported capabilities for PVH Marek Marczykowski-Górecki (5): libxl: reorder libxlMakeDomBuildInfo for upcoming PVH support libxl: add support for PVH tests: add basic Xen PVH test xenconfig: add support for parsing type= xl config entry xenconfig: add support for type="pvh" docs/formatcaps.html.in | 4 +- docs/schemas/domaincommon.rng | 1 +- src/conf/domain_conf.c | 6 +- src/libxl/libxl_capabilities.c | 47 +++--- src/libxl/libxl_conf.c | 76 -- src/libxl/libxl_driver.c| 6 +- src/xenconfig/xen_common.c | 27 ++-- src/xenconfig/xen_xl.c | 5 +- tests/libxlxml2domconfigdata/basic-pvh.json | 49 ++- tests/libxlxml2domconfigdata/basic-pvh.xml | 28 - tests/libxlxml2domconfigtest.c | 3 +- tests/testutilsxen.c| 3 +- tests/xlconfigdata/test-fullvirt-type.cfg | 21 ++- tests/xlconfigdata/test-fullvirt-type.xml | 27 - tests/xlconfigdata/test-paravirt-type.cfg | 13 - tests/xlconfigdata/test-paravirt-type.xml | 25 +++- tests/xlconfigdata/test-pvh-type.cfg| 13 - tests/xlconfigdata/test-pvh-type.xml| 25 +++- tests/xlconfigtest.c| 3 +- 19 files changed, 346 insertions(+), 36 deletions(-) create mode 100644 tests/libxlxml2domconfigdata/basic-pvh.json create mode 100644 tests/libxlxml2domconfigdata/basic-pvh.xml create mode 100644 tests/xlconfigdata/test-fullvirt-type.cfg create mode 100644 tests/xlconfigdata/test-fullvirt-type.xml create mode 100644 tests/xlconfigdata/test-paravirt-type.cfg create mode 100644 tests/xlconfigdata/test-paravirt-type.xml create mode 100644 tests/xlconfigdata/test-pvh-type.cfg create mode 100644 tests/xlconfigdata/test-pvh-type.xml base-commit: 199eee6aae7af3d813fbe98660c7e0fa1a8ae7b7 -- git-series 0.9.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list