[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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?
At that point, it might be better to rip all the current code off and
start from scratch.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.