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

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

On 06/05/2015 01:16 PM, 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?
> At that point, it might be better to rip all the current code off and
> start from scratch.
I suspect that doing what Andrew is suggesting will result in most/large 
portion of the code to be replaced (i.e. it's not "better to rip" it 
off, it will just happen organically).
-boris

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