[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] RFC: making the PVH 64bit ABI as stableo
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. > 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@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |