PVH hypercall interface

PVH hypercall interface

[Marek Marczykowski-Górecki]

[-- Attachment #1.1: Type: text/plain, Size: 540 bytes --]

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?

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: PVH hypercall interface

[Andrew Cooper]

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

Re: PVH hypercall interface

[Roger Pau Monne]

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: PVH hypercall interface

[Marek Marczykowski-Górecki]

[-- Attachment #1.1: Type: text/plain, Size: 2264 bytes --]

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?

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: PVH hypercall interface

[Boris Ostrovsky]

[-- Attachment #1.1.1: Type: text/plain, Size: 603 bytes --]

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



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel