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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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@xxxxxxxxxxxxx> 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.

~Andrew

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