Re: [Xen-devel] [PATCH v1 0/8]: PVH (PV guest with extensions)

[Konrad Rzeszutek Wilk <konrad@xxxxxxxxxx>]

On Thu, Oct 4, 2012 at 4:15 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> On Wed, 2012-10-03 at 21:39 +0100, Konrad Rzeszutek Wilk wrote:
>> > You Ok with XEN_ELFNOTE_GUEST_PVH, or should I call it
>> > XEN_ELFNOTE_PV_EXTENSIONS. Please LMK.
>
> My intention was that you add XENFEAT_supervisor_mode_kernel et al. to
> the existing XEN_ELFNOTE_FEATURES note rather than adding a whole new
> note. I some how missed that this is what you were doing above. e.g.
> what I meant was:
>
> in Kconfig:
> config XEN_X86_PVH
>         bool "Support for running as a PVH guest (EXPERIMENTAL)"
>         depends X86_64 && <..etc..> && EXPERIMENTAL
>         help
>                         This option enables support for running as a PVH
>                         guest (PV guest using hardware extensions) under
>                         a suitably capable hypervisor.
>
>                         This option is EXPERIMETNAL because the
>                         hypervisor interfaces which it uses are not yet
>                         considered stable therefore backwards and
>                         forwards compatibility is not yet guaranteed.
>
>                         If unsure, say N.
>
> Adjust the depends to suit reality.
>
> I thought we had that second paragraph for ARM too, but it seems like I
> was wrong, we should probably add it.
>
> then in xen-head.S (adjusted for features actually used by PVH):
> #ifdef CONFIG_XEN_X86_PVH
> #define FEATURES_PVH "XENFEAT_writable_descriptor_tables|" \
>                      "XENFEAT_auto_translated_physmap|" \
>                      "XENFEAT_supervisor_mode_kernel" \
>                      "XENFEAT_hvm_callback_vector"
> #else
> #define FEATURES_PVH /* Not supported */
> #endif
> ...
> ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,       .asciz 
> "!writable_page_tables|pae_pgdir_above_4gb"FEATURES_PVH)

As long as those new fields exists with the older hypervisors - that
is OK. If you define new
ones the old hypervisors (say Xen 4.1) will refuse booting the kernel.

> ...
>
> I don't think we need to define a XENFEAT_pvh (or whatever it might be
> called) since don't need it in the code so there's no need to define/use
> it here. If/when we need something like that we can add it, or
> preferably some more specific thing for the use case which crops up.
>
>> XEN_ELFNOTE_PVH_FEATURES ?
>>
>> That way you can fill it with different 'features' flags
>> if need to. Say 1<<1 is basic, etc.
>
> I don't think we need a PVH specific ELF note which just replicates the
> XENFEAT infrastructure at this stage, if we do come to that then it
> would be better to give PVH its own leaf in the existing feature space
> (e.g. starting at 1*32+0).
>
> 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