[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] RFC: making the PVH 64bit ABI as stableo
El 05/06/15 a les 23.52, Tim Deegan ha escrit: > 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). I agree that using a boot ABI similar to multiboot1 is going to solve some of the issues that we currently have, while probably simplifying the code to build a domain. There are also several multiboot1 implementations around which can be used as a basis for this for guest OSes that don't have native multiboot support. >>>> 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? I don't think the ABI is going to change much, most of this plumbing is going to be in Xen internals, so I wouldn't call it a drastic change. >> 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. I believe the right way to move forward is to start implementing this new boot ABI on top of HVM, without axing out the PVH code. I think most of the current PVH code would still be needed for the HVM-without-dm kind of guest, and that at some point both will meet. I will send a design document for this boot ABI next week, but the plan is as follows: - Start the guest in protected mode without paging. - Fill the hypercall page using wrmsr (HVM). - Map the shared info page using XENMEM_add_to_physmap (HVM). That means we can get rid of some of the ELFNOTES, the ones that come to mind right now are: - XEN_ELFNOTE_VIRT_BASE - XEN_ELFNOTE_HYPERCALL_PAGE - XEN_ELFNOTE_HV_START_LOW - XEN_ELFNOTE_PAE_MODE - XEN_ELFNOTE_L1_MFN_VALID And probably some more. Roger. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |