Re: [Xen-devel] RFC: making the PVH 64bit ABI as stableo

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 02/06/15 17:51, Stefano Stabellini wrote:
> On Tue, 2 Jun 2015, Jan Beulich wrote:
>>>>> On 02.06.15 at 17:11, <roger.pau@xxxxxxxxxx> wrote:
>>> Hello,
>>>
>>> The document describing the PVH interface was committed 9 months ago
>>> [1], and since then there hasn't been any change regarding the
>>> interface. PVH is still missing features in order to have feature parity
>>> with pure PV, mainly:
>>>
>>>  - DomU miration support.
>>>  - PCI passthrough support.
>>>  - 32bit support.
>>>  - AMD support.
>>>
>>> AFAICT however none of these features are going to change the current
>>> ABI.
>> This your guess; I don't think there's any guarantee.
> Let's make it a guarantee.

No.  Lets fix it.

>
>> The more that talk was about making PVH uniformly enter the kernel in
>> 32-bit mode.
> What talk?

At the hackathon.

>  IRL talks are irrelevant in this context. If it is not on the
> list, it doesn't exist.
>
>
>>> PCI passthrough might expand it, by adding new hypercalls, but I
>>> don't think this should prevent us from marking the current ABI as
>>> stable. ARM for example doesn't have PCI passthrough yet or migration
>>> support, but the ABI has been marked as stable.
>>>
>>> To that end, I would like to request the 64bit PVH ABI to be marked as
>>> stable for DomUs. This is needed so external projects (like PVH support
>>> for grub2) can progress.
>> Understandable, but no, not before all the fixmes in the tree got
>> dealt with.
> What is your timeline for that? In fact does anybody have any timelines
> for it?
>
> We need to have a clear idea of what exactly needs to happen. We also
> need to have confidence that is going to happen in a reasonable time
> frame. At the moment we have some various mumblings about things, but we
> don't have a clear breakdown of the outstanding work and names
> associated with each work item.
>
> Is anybody going to volunteer writing that todo list?
>
> Are we going to be able to find enough volunteers with the right skills
> to be confident that PVH is going to be out of "experimental" within a
> reasonable time frame? It is clear that some of the clean-ups require an
> hypervisor expert.
>
> If not, I suggest we rethink our priorities and we consider dropping PVH
> entirely. I don't think is fair to expect Roger or anybody else to keep
> their efforts up on PVH, when actually we don't know if we'll be able to
> land it.
>
> Maybe we could focus on improving PV on HVM and its security. Maybe we
> could resurrect Intel's HVM Dom0 project
> (http://events.linuxfoundation.org/sites/events/files/slides/HVM%20Dom0.pdf).
> Think of how much farther we would be if we didn't start PVH in the
> first place.
>
>
> P.S.
> This message is not addressed to Jan in particular but to the larger Xen
> community.

Boris: sorry if this comes as news to you, but you were volunteered in
absentia by your manager at the hackathon ;)

With my x86 maintainer hat on, the following is an absolute minimum set
of prerequisite for PVH.

* 32bit support
* AMD support
* Removal of all /* TODO pvhfixme */ from the code

OTOH, I do not see PCI Passthough or Migration as blockers to tech preview.

All three of these issues can be addressed by ceasing to think of PVH as
PV + hardware virt, and by thinking of PVH as HVM without qemu.  At this
point, PVH and HVM are basically identical from Xens point of view.

It is my strong oppinion that all PVH guests should start in 32bit flat
mode (curiously the same as a multiboot entry, hint hint, which I expect
all mainstream kernels to already have entry points for) at which point
they can do whatever they like 32/64bit wise and pagetable wise, and we
are not in the same position as we are with current PV guests where we
need to know the bitness of them ahead of domain construction.

~Andrew

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