Re: RFC: making the PVH 64bit ABI as stableo

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 05/06/15 18:16, Stefano Stabellini wrote:
> On Fri, 5 Jun 2015, Andrew Cooper wrote:
>> On 05/06/15 17:43, Boris Ostrovsky wrote:
>>> On 06/05/2015 12:16 PM, Roger Pau Monné wrote:
>>>> El 03/06/15 a les 14.08, Jan Beulich ha escrit:
>>>>>>>> On 03.06.15 at 12:02, <stefano.stabellini@eu.citrix.com> wrote:
>>>>>> On Tue, 2 Jun 2015, Andrew Cooper wrote:
>>>>>>> With my x86 maintainer hat on, the following is an absolute
>>>>>>> minimum set
>>>>>>> of prerequisite for PVH.
>>>>>>>
>>>>>>> * 32bit support
>>>>>> Could you please explain why 32bit is important to get PVH out of tech
>>>>>> preview? I don't see 32 bit OSes as an important use case. Maybe there
>>>>>> is more behind it that I cannot see.
>>>>> The primary reason was named before: 32-bit support will likely
>>>>> end up changing the way 64-bit guests get launched.
>>>> I can work on the new boot ABI, even if it's just a design document now,
>>>> but the actual implementation needs to be done on top of the 32-bit
>>>> support series.
>>>>
>>>> Boris, do you think you could send an early RFC of your 32-bit support
>>>> series in a couple of weeks at most?
>>> That's highly unlikely. For one, I am still unable to boot MP guests.
>>> In addition, it is all held together by rubber bands and matchsticks
>>> so calling it an RFC would be an insult to RFCs. (for example, I
>>> apparently broke HVM somewhere along the way).
>> How about working it the other way around.
>>
>> Start with an HVM guest and start with a sane method of booting.  I
>> highly suggest multiboot1 as it is very easy and we have most of the
>> code already.  Whomever actually gets around to doing this gets leeway,
>> subject to it being sane (which the current method very certainly is not).
>>
>> Start the domain without qemu, and expose some of the PV hypercalls to
>> HVM guests, and see how far it gets.  One will find suddenly that all
>> 32bit and AMD problems have already been solved.  All the PV(h) kernel
>> needs to know is that there is no real hardware, and not to touch it.
> This seems like a clean and nice way forward, but rather than PVH is
> actually something else.  Am I the only one to think that making this
> drastic change in the design at this stange (3 years in) is too late?

There was no design in the slightest, which is why we have got 3 years
in and are in this position.

> At that point, it might be better to rip all the current code off and
> start from scratch.

With a maintainers hat on, I am happy with any solution (including
ripping it all out and starting from scratch) which ends up in the
correct position.

However, I expect it to turn into (HVM - Qemu + very few extra PV
hypercalls) which would probably be better developed straight on top of
HVM guests.

~Andrew

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