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

[Tim Deegan <tim@xxxxxxx>]

At 18:21 +0100 on 05 Jun (1433528517), Andrew Cooper wrote:
> 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@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.
> > 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.

Please try to keep things friendly and contructive on this list.  Yes,
there was design; it was discussed on this list and at the Xen summit.
With hindsight, it turned out that "PV guest that uses a lightweight
HVM container" took a lot more work/code than was originally expected.

I suspect that an implementation of "HVM without qemu and some
hypercalls" will also turn out more complex than it sounds.  I believe
I've made my opinion clear that that's where PVH ought to end up, but
I'm unconvinced that starting from scratch will be the fastest way.

Tim.

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