Re: [Xen-devel] PVH hypercall interface
On 08/08/2016 08:13 AM, Marek Marczykowski-Górecki wrote: > Thanks for the explanation. What is the current state of HVMlite? I see > "none" is valid value for "device_model_version" already, but if I try > to start such guest, it fails at x86_compat call (tries to boot it as PV > guest). I guess it's because of missing kernel support. Is "[PATCH v2 > 00/11] HVMlite domU support" sent in Feb the latest version available? > When it is planned to have it in vanilla kernel? This has been delayed by ACPI rework in Xen. I will post Linux domU patches as soon as that is done. -boris signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] PVH hypercall interface
On Mon, Aug 08, 2016 at 01:19:43PM +0200, Roger Pau Monne wrote: > On Mon, Aug 08, 2016 at 11:42:03AM +0100, Andrew Cooper wrote: > > On 08/08/16 11:21, Marek Marczykowski-Górecki wrote: > > > Hi, > > > > > > What hypercalls are available for PVH guests? > > > > First of all, be aware that there is currently some chaos in the > > codebase which is soon to be resolved. > > > > What you are looking for is HVMLite, which will likely be renamed to PVH > > once it is complete. Original PVH will then be filed in /dev/null, > > leaving only a set of lessons in git history. > > > > > How is it different for HVM guests? > > > > HVMLite guests are just HVM guests without qemu. > > > > Roger (CC'd) is leading the effort. You select an HVMLite guest by > > choosing device-model = None in the xl configuration file, rather than > > setting pvh=1 > > > > > Is it documented somewhere? > > > > There are patches on the list. > > > > Also, docs/misc/hvmlite.markdown > > > > > For example I'd expect that do_mmu_update is available only for PV > > > guests, but looking at the code I can't find anything preventing other > > > guest types from using it (no, some obscure conditions deep in execution > > > path doesn't count). > > > > HVM guests use the hvm_hypercall_table, not the hypercall tables in entry.S > > They have access to the same set of hypercalls as HVM guests, in fact the > hypercall table is shared between HVM and HVMlite guests (to become PVH, > just using HVMlite here to avoid confusion). Classic PVH guests had their > own hypercall table, but as Andrew said you should not look at those. Thanks for the explanation. What is the current state of HVMlite? I see "none" is valid value for "device_model_version" already, but if I try to start such guest, it fails at x86_compat call (tries to boot it as PV guest). I guess it's because of missing kernel support. Is "[PATCH v2 00/11] HVMlite domU support" sent in Feb the latest version available? When it is planned to have it in vanilla kernel? -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? signature.asc Description: PGP signature ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] PVH hypercall interface
On Mon, Aug 08, 2016 at 11:42:03AM +0100, Andrew Cooper wrote: > On 08/08/16 11:21, Marek Marczykowski-Górecki wrote: > > Hi, > > > > What hypercalls are available for PVH guests? > > First of all, be aware that there is currently some chaos in the > codebase which is soon to be resolved. > > What you are looking for is HVMLite, which will likely be renamed to PVH > once it is complete. Original PVH will then be filed in /dev/null, > leaving only a set of lessons in git history. > > > How is it different for HVM guests? > > HVMLite guests are just HVM guests without qemu. > > Roger (CC'd) is leading the effort. You select an HVMLite guest by > choosing device-model = None in the xl configuration file, rather than > setting pvh=1 > > > Is it documented somewhere? > > There are patches on the list. > > Also, docs/misc/hvmlite.markdown > > > For example I'd expect that do_mmu_update is available only for PV > > guests, but looking at the code I can't find anything preventing other > > guest types from using it (no, some obscure conditions deep in execution > > path doesn't count). > > HVM guests use the hvm_hypercall_table, not the hypercall tables in entry.S They have access to the same set of hypercalls as HVM guests, in fact the hypercall table is shared between HVM and HVMlite guests (to become PVH, just using HVMlite here to avoid confusion). Classic PVH guests had their own hypercall table, but as Andrew said you should not look at those. Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] PVH hypercall interface
On 08/08/16 11:21, Marek Marczykowski-Górecki wrote: > Hi, > > What hypercalls are available for PVH guests? First of all, be aware that there is currently some chaos in the codebase which is soon to be resolved. What you are looking for is HVMLite, which will likely be renamed to PVH once it is complete. Original PVH will then be filed in /dev/null, leaving only a set of lessons in git history. > How is it different for HVM guests? HVMLite guests are just HVM guests without qemu. Roger (CC'd) is leading the effort. You select an HVMLite guest by choosing device-model = None in the xl configuration file, rather than setting pvh=1 > Is it documented somewhere? There are patches on the list. Also, docs/misc/hvmlite.markdown > For example I'd expect that do_mmu_update is available only for PV > guests, but looking at the code I can't find anything preventing other > guest types from using it (no, some obscure conditions deep in execution > path doesn't count). HVM guests use the hvm_hypercall_table, not the hypercall tables in entry.S ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] PVH hypercall interface
Hi, What hypercalls are available for PVH guests? How is it different for HVM guests? Is it documented somewhere? For example I'd expect that do_mmu_update is available only for PV guests, but looking at the code I can't find anything preventing other guest types from using it (no, some obscure conditions deep in execution path doesn't count). -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? signature.asc Description: PGP signature ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
